Hello, Am 01.01.2013 um 18:25 schrieb NicoEchániz: That's quite frustrating. Can I debug, when and why batman-adv actually chooses as specific gateway? Thanks, Keep smiling yanosz

Hello, Am 03.01.2013 um 02:57 schrieb Marek Lindner: Ok, Let's give it a try: === Command Log a) Situation on node at beginng - just one gateway, the right one. Freifunk-b0487acb2d58:~# batctl gwl Gateway (#/255) Nexthop [outgoingIF]: gw_class ... [B.A.T.M.A.N. adv 2012.4.0, MainIF/MAC: wlan0-1/b2:48:7a:cb:2d:59 (bat0)] => 72:8b:06:40:61:2e (248) 72:8b:06:40:61:2e [ mesh-vpn]: 215 - 96MBit/96MBit b) Enable gateway mode on the backup gateway root@fastd3:~# /usr/local/sbin/batctl gw server 1Mbit/1Mbit Gateway-List is: Freifunk-b0487acb2d58:~# batctl gwl Gateway (#/255) Nexthop [outgoingIF]: gw_class ... [B.A.T.M.A.N. adv 2012.4.0, MainIF/MAC: wlan0-1/b2:48:7a:cb:2d:59 (bat0)] => 72:8b:06:40:61:2e (255) 72:8b:06:40:61:2e [ mesh-vpn]: 215 - 96MBit/96MBit aa:31:0e:4a:0f:1d (255) aa:31:0e:4a:0f:1d [ mesh-vpn]: 39 - 1024KBit/1024KBit c) Disable regular gateway, force node to switch to backup kif:~# batctl gw_mode client Gateway-List is: reifunk-b0487acb2d58:~# batctl gwl Gateway (#/255) Nexthop [outgoingIF]: gw_class ... [B.A.T.M.A.N. adv 2012.4.0, MainIF/MAC: wlan0-1/b2:48:7a:cb:2d:59 (bat0)] => aa:31:0e:4a:0f:1d (255) aa:31:0e:4a:0f:1d [ mesh-vpn]: 39 - 1024KBit/1024KBit d) Re-enable regular gateway root@kif:~# /usr/local/sbin/batctl gw server 100Mbit/100Mbit Gateway-List is Freifunk-b0487acb2d58:~# batctl gwl Gateway (#/255) Nexthop [outgoingIF]: gw_class ... [B.A.T.M.A.N. adv 2012.4.0, MainIF/MAC: wlan0-1/b2:48:7a:cb:2d:59 (bat0)] 72:8b:06:40:61:2e (254) 72:8b:06:40:61:2e [ mesh-vpn]: 215 - 96MBit/96MBit => aa:31:0e:4a:0f:1d (255) aa:31:0e:4a:0f:1d [ mesh-vpn]: 39 - 1024KBit/1024KBit e) Wait some time f) Stop Logging === End of command Log === Node log of that hour http://jluehr.de/batman-adv.log.gz zgrep -i gateway batman-adv.log.gz [ 1022240] Gateway class of originator aa:31:0e:4a:0f:1d changed from 0 to 39 [ 1035100] Gateway class of originator 72:8b:06:40:61:2e changed from 215 to 0 [ 1035100] Gateway 72:8b:06:40:61:2e removed from gateway list [ 1035830] Changing route to gateway aa:31:0e:4a:0f:1d (gw_flags: 39, tq: 255) [ 1046020] Gateway class of originator 72:8b:06:40:61:2e changed from 0 to 215

Hello, Am 03.01.2013 um 15:58 schrieb Marek Lindner: It is. - Sorry, forgot to mention: Freifunk-b0487acb2d58:~# batctl gw_mode client (selection class: 1) => 1 -> fast connection consider the gateway's advertised throughput as well as the link quality towards the gateway Keep smiling yanosz

On 01/03/2013 12:14 PM, Marek Lindner wrote: Marek, could you please clarify this? gw_mode|gw [off|client|server] [sel_class|bandwidth] [...] If the node is a gateway client the parameter will decide which criterias to consider when the batman-adv module has to choose between different internet connections announced by the afore- mentioned servers. default: 20 -> late switch (TQ 20) examples: 1 -> fast connection consider the gateway's advertised throughput as well as the link quality towards the gateway 2 -> stable connection chooses the gateway with the best link quality and stick with it (ignore the advertised throughput) 3 -> fast switch connection chooses the gateway with the best link quality but switches to another gateway as soon as a better one is found XX -> late switch connection chooses the gateway with the best link quality but switches to another gateway as soon as a better one is found which is at least XX TQ better than the cur- rently selected gateway (XX has to be a number between 3 and 256). Would mode 3 accomplish this fast switching? It doesn't mention if this mode will consider advertised throughput or not; only selection class 1 mentions throughput. -- NicoEchániz

On 01/03/2013 09:39 PM, Marek Lindner wrote: I believe that those of us who chose to use selection class 1 would prefer if it were "dynamic". So if a new gateway appears, then the client would evaluate with the same previous criteria if it is better or not (considering "the gateway's advertised throughput as well as the link quality") and switch accordingly. I see no reason why when someone chooses selection class 1 she would be expecting to choose the best available gw once and not ever check again. If a network is stable, when a new better gw appears in some area it won't be selected until nodes are restarted, and that might be a long time. In my town, where partial energy outages are frequent, I've had to manually switch off gw_mode and play around with this from time to time because clients would be stuck with the wrong gw after an energy shortage in the main gw. One other change that might be interesting would be the addition of a setting for how much the advertised throughput affects gw selection. I've seen Jan uses 96/96Mbit as advertised throughput on one router; I do the same on our "main gateway", but maybe it would be better if we could actually advertise the real throughput and have a setting to control how much the bandwidth difference affects the selection. good, it reads better now :) Cheers, NicoEchániz

Hello, Am 04.01.2013 um 18:41 schrieb Marek Lindner: Thanks for being open minded. Imho there are a few "tweaks" for doing so. For our networks, it's not important, that all clients choose the gateway with the highest data rate. Basically, we have 3 gateway-types -> Regular Gateways, that should be used if they are reachable (above a certain TQ threshold) -> Backup Gateways - Gateways, that should be used if no regular Gateway is available. -> Test Gateways - Just for testing purpose - should be used if no Backup-Gateway is available. Imho others may have more / or less classes. basically what is needed here is a positive gateway ("route priority") - imho the already existing gateway-class may be used for doing so. In order to prevent "switching immediately as soon as a better gateway comes around", we may can go this way: gw_mode client may have three parameters: 1st: Switching threshold based on TQ (Like today, eg 20: late switching) 2nd: Switching threshold based on Gateway Class). GC-Thresh 3rd: LQ-Threshold for GW-class-switch GC-TQ-Thresh Meaning: Switch gateway to same / better class, if there is a Gateway having TQ xx-Times bigger (traditional late switching with xx) Switch gateway to a better class, if a Class is GC-Thresh times better, and LQ is above TQ-GC-Thresh Switch gateway to a worse class, if all existing gateway of same or better class have LQ < GC-TQ-Thresh However, this is quite complex and I don't know if everybody will be happy with this - However, I'll be so. For backwards compatibility, old configurations can be detected by counting the number of parameters and react according old defaults. If you like thinks to be more complex - Different thresholds for blocking DHCPDISCOVER / DHCPREQUEST ;-) Thanks, Keep smiling yanosz

On 01/04/2013 02:41 PM, Marek Lindner wrote: Yeah, I agree. The gateway switching should be regulated by a threshold, so that it won't be switching like crazy when a client has similar ranking values from more than one gw. See the proposal below... It could just be implemented as a new setting like: gw_bw_weight which would regulate how much gw bandwidth/throughput affects best gw calculation. I don't know what's the current algorithm but I guess there would be no problem with backwards compatibility here; if the value is not set, the default should produce the same result we get now. So to make the proposal clear: I'd change options for gw_mode client to something like this: gw_sel_class [1|2] (1 considers TQ and bw, 2 only considers TQ) gw_tq_threshold [3...256] the minimum TQ delta to switch to a better gw, defaults to 20. gw_bw_weight [value from 0 to 1] how much does advertised gw bandwidth affect the selection. 0 does not affect selection, 1 has most effect. Defaults to 1 but has no effect if gw_sel_class is 2. For backwards compatibility, if gw_sel_class > 2, it should behave as the proposed option 2 with gw_tq_threshold set to the actual value. So, for example gw_sel_class 20 would be "translated" to: gw_sel_class 2, gw_tq_threshold 20, al least until it's deprecated. The advantage of this proposal is that we can have a tq_threshold that can still be used in the mode that considers gw throughput. I like this better than gateway classes that Jan proposed, as it is less implementation specific. Please let me know if anything in this proposal is not sufficiently clear. cheers, NicoEchániz PS: Marek, there are mismatched parenthesis in the new man page text in this paragraph: The second (optional) argument specifies the selection class (if 'client' was the first argument) or the gateway bandwidth (if this node's internet connection bandwidth. Just enter any number (optionally followed by "kbit" or "mbit") and the batman-adv module will guess your appropriate gateway class.

Hello, Am 05.01.2013 um 00:28 schrieb NicoEchániz: I guess, we'll be fine with this. However, it's not clear to me, in what way (formula) gw_bw_weight will actually influence the selection process. Do you have any proposals? Thanks Keep smiling yanosz

On Monday, January 07, 2013 23:26:10 Jan Lühr wrote: May I propose that we schedule an IRC discussion for this topic ? I lost track of what you are actually trying to achieve and I see things getting more and more complicated. Whatever idea you come up with keep in mind that somebody has to do the following before this solution can be merged: * batman-adv code has to be written, tested & debugged * batman-adv kernel doc has to be written * batctl code has to be written, tested & debugged * man page has to be updated * user documentation for $your_new_mechanism has to be written Unless you manage to convince somebody else to do the work for you that somebody who has to do all work will be you. In other words: It is in your best interest to keep things as simple as possible. :-) Cheers, Marek

On Wednesday, January 09, 2013 00:35:17 NicoEchániz wrote: I am idling on IRC most of the time. Depends on you guys. Cheers, Marek

On 01/09/2013 08:49 AM, Jan Lühr wrote: I'm also idling on IRC usually; next week is ok; Jan what about monday or twesday?.

Hi all, I wanted to share this proposal we arrived at after discussion with some AlterMundi hackers, so we can discuss it during our future IRC session. I've previously shared it with yanosz, who had some observations that he can better explain, but agreed on this initial assumption which triggered the proposal: The scenario we see in our networks is that over a certain link quality which is considered acceptable, we want the clients to choose the gw with better bandwidth. So if for example this quality floor is TQ 100, then if a gw has 6Mbit/s advertised b/w and another has 3Mbit/s, the clients that see this gateways with a TQ above 100 will choose the faster one between them. We observed that in the current implementation, advertized gateway throughput is used to modify the final gw selection by publishing unrealistic bandwidth. The proposal tries to fix this, as well as the "dynamic switching" for selection class 1. Looking at the current code involved we also believe it would allow to make the implementation simpler. This would be the proposed options: gw_sel_class [1,2] 1 will consider gw throughput, 2 will only consider TQ. When using selection class 1, clients will switch gateways if one with better throughput becomes available and reachable with a TQ above gw_tq_floor (see below). Defaults to 2. gw_tq_floor Only relevant for gw_sel_class 1. Above this TQ floor, the gw with the best advertised throughput will be chosen.* Defaults to 100(?) gw_tq_threshold TQ delta that triggers a gw switch in the client. If gw_sel_class is 1, the tq_threshold will only be considered to choose between two or more gateways advertising the same winning throughput on the net. Defaults to 20. The old config options would be deprecated but to maintain backwards compatibility, if gw_sel_class is set to... say 20, it would be internally translated as: gw_sel_class 2 gw_tq_threshold 20 I believe this proposal maintains current behavior for sel_class>1 while IMHO it better handles sel_class 1. Cheers, NicoEchániz * if no gw can be reached with TQ over the tq_floor, the client should choose one anyway, probably the one with better TQ; this should be discussed further. Another option would be to choose no gateway and the network admins should fix the net :) or lower the tq_floor values.