Hi Ilario,
Thank you for your email.
I apologize for the delay in response, as I encountered some issues with
the automated configurations of the routers in the network profiles. It
seems there were some glitches with the recent changes, resulting in the
profiles not appearing in the menuconfig as expected.
I'm glad to hear that you found the tests on Pony to be beneficial. I
didn't encounter any major issues during my testing either. However, I
did notice a slight delay in roaming when testing with a Xiaomi device.
On the brighter side, I successfully tested multiple WAN outputs, and
everything seemed to be functioning smoothly. Additionally, I
experimented with a local server connected to one of the nodes, and the
connection worked well.
I'm excited to hear about the upcoming release of lime-app by Selankon!
As for the current status of the code, I believe we're making good
progress, but a release candidate would definitely help in conducting
more rigorous testing, especially in real-world scenarios with numerous
clients.
One thing that's been on my mind lately is the peculiar behavior of some
older versions like the wdr3500. It's been exhibiting some strange
behavior which I'm currently investigating.
On another note, I wanted to mention that my testing setup has been
somewhat reduced as I haven't been able to compile and configure the
librerouter due to the multiple partitions issue. Therefore, my setup
has been similar to this
(
https://raw.githubusercontent.com/libremesh/network-profiles/master/LibremeshTestBed/diagram.png),
except for the absence of the librerouter.
Looking forward to the next project meeting.
Abraços
Hiure
On 13/03/2024 10:43, Ilario via LibreMesh wrote:
> Thanks Pony for the amazing quality of the testing!
> You proposed many fixes that are going to improve the quality of the
> next release A LOT.
> If it is ok for you, in the next project meeting the funds for the
> second half of the "testing grant" payment will be made available :D
>
> One curiosity: the IEEE802.11r roaming, it works only when psk2 (WPA2)
> is used, right? Or would it help even with open networks?
>
> I heard that Selankon is preparing a new release of lime-app (!!!!).
>
> Hiure, what do you think about the current status of the code?
>
> @all, what about creating a LibreMesh release candidate as soon as we
> have the lime-app release?
>
> Ciao!
> Ilario
>
>
>
> On 2/24/24 20:57, pony via LibreMesh wrote:
>> Hi!
>>
>> Here comes my test report.
>>
>> I used the following topologies for testing:
>>
>> Topology #1
>> internet1
>> ~wifi~
>> dual_band#1
>> ~wifi~
>> dual_band#2
>> -cable-
>> single_band#1
>> ~wifi~
>> single_band#2
>> -cable-
>> internet2
>> Topology #2
>> internet1
>> -cable-
>> dual_band#1
>> ~wifi~
>> dual_band#2
>> -cable-
>>
>> single_band#1
>> ~wifi~
>> dual_band#3 (non-dsa)
>> -cable-
>> dual_band#4
>> ~wifi~
>>
>> dual_band#5
>> -cable-
>> single_band#2
>> -cable-
>> internet2
>>
>> In Topology #2, the first two, middle three and last two nodes were
>> configured as 3 seperate mesh-clouds (seperate ssids and layer 2
>> domain).
>> I left the ethernet interfaces connecting to other routers inside
>> br-lan ("lime proto lan"). batadv has a feature called Bridge Loop
>> Avoidance that can handle this.
>>
>> This is the hardware that was used:
>> single_band#1 TP-LINK TD-W8970
>> single_band#2 TP-LINK TD-W8970
>> dual_band#1: Xiaomi Redmi Router AX6S
>> dual_band#2: TP-Link RE650 v1
>> dual_band#3: TP-Link Archer C20i
>> dual_band#4: TP-Link Archer C6 v3
>> dial_band#5: MERCUSYS MR70X v1
>>
>> The following experiments were conducted:
>> i) Automatic switching of default gateway: I checked that when
>> internet1 is down, internet2 is used. When internet2 is down,
>> internet1 is used. Each for both wifi and cable clients.
>> ii) Lease sharing: The dhcp-leases are distributed in the network. I
>> checked that a node does not give an ip address to a client that
>> another node has given to another client.
>> iii) Roaming: Roaming was triggered with wpa_cli roam command, while
>> pinging the default gateway (anygw address). Sadly, the connection
>> was interrupted for about 1100ms every time. I then placed the two
>> routers at distant places and walked back and forth between them.
>> Still the connection was interrupted for at least 1100ms when
>> switching APs. I tried intel 7260, RTL8814AU and a shift5me
>> smartphone as client device, with similiar results. I don't know why
>> this is. Maybe my devices are just crappy. Even without 802.11r, it
>> shouldn't be more than 200ms. I don't know for sure if any of my wifi
>> client devices support 802.11r fast transition. 802.11r should, with
>> the right settings, reduce the interruption to below 50ms.
>> iv) Local DNS: DNS resolution of hosts in the network worked fine.
>>
>> To enable 802.11r fast transition support on a node, it should be
>> sufficient to put
>>
>> option ap_ieee80211r '1'
>> option ap_reassociation_deadline '20000'
>> option ap_ft_psk_generate_local '1'
>> option ap_ft_over_ds '0'
>>
>> into the "config lime wifi" section inside the lime-node or
>> lime-community file.
>>
>> Attached you find
>> - all lime-node and lime-community files that I used.
>> - pack lists for imagebuilder that I used to make up to date images.
>> - some logs
>> - a python script that I wrote to measure connection interruption
>> times during roaming using ipv6 ping.
>>
>> Have I forgot something? Let me know if there are any questions.
>>
>> Liebst
>> Pony
>>
>>
>
