-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change OpenWRT wrapper scripts so wired interfaces are more tunable. #43
Comments
@jheretic Could you describe the condition for the static static plugability option and the gateway override? I need to create the help text for the "why" of them. |
After reflecting on the old notes in this issue, your proposed options in the other issue, which options are mutually exclusive, and our previous conversation, here are my new proposed options. These are actually potentially valid for all three types of interfaces, in that I realized that all the different default functionality for interfaces can be encapsulated by these three options. Also, I realized that a manual switch for 'gateway' is global, and not specific to a given interface. Given the potential for abuse, we should probably hold off of allowing a manual gateway switch until we have #52. option meshed (true/false) : controls whether this interface passes OLSR traffic. Default off for ap & plug, on for mesh. option announced (true/false) : controls whether the subnet on this interface is advertised as an HNA. Default true for ap, and for plug acting as a dhcp server, but default false for mesh and for plug acting as a DHCP client. option dhcp (client, server, none, auto) : client always attempts to get a DHCP lease. Server always attempts to hand one out. None does not attempt to do anything with DHCP; it just attempts to configure the interface. Auto is the current default functionality. Default auto for plug, server for ap, and none for mesh. |
This has been implemented in the plugins branch, soon to be merged to master. |
Right now, interfaces configured to use the 'commotion' protocol have most of their attributes statically determined by the type of interface they are. However, we should support different tunable parameters in order to better support custom setups. These are:
The first two parameters should exclusive (you shouldn't be able to mesh over a client network), and while the first two should boolean the third would support 4 different options plus an optional true/false gateway override option.
The text was updated successfully, but these errors were encountered: