Closed rspelta closed 7 years ago
Is it possible that issue #298 and the necessity for high ring buffer sizes are two different faces of the same issue?
Reading the packets from the ethernet I don't think so. The issue #298 happen when the client sends all the right packets but the mbed server doesn't replies (in this case the border router is innocent). However the issue #298 force the client to send more packets than the usual in order to connect to the mbed server. So with many clients, this issue doesn't help if the size of the ring buffer is too short.
About the size of the buffer, what I see from the sniffing is that after the "Server Hello Done" message from the server, the client sends 5 packets very quickly and the border router must read them very quickly in order to send them to the mbed server. So if there are a lot of clients that send 5 packets may be that the border router fails to read all of them with a buffer size too short. This for me could exaplain why there are more fails with a short buffer rather than a bigger buffer. Sounds good to you?
@rspelta not sure I understood your point above.
In the meanwhile I have made the number of TX/RX DMA buffer elements configurable (via mbed config system).
The issue 298 for me is a problem from the mbed server not from the border router because I don't see the reply from the mbed server. But yes the high ring buffer size is needed also for that issue.
Does this mean that once the mbed server issue gets resolved you think that you might downsize the ring buffer again?
I think it can work better. The configurable TX/RX DMA buffer is a perfect solution for my case. I will downsize the ring buffer only if there will be memory problem or if you suggest to do so.
All, do you think we can close this issue?
For me ok. Thanks you all!
Any remaining problems visible on the radio side at present?
I don't know if all my long-ago comments on radio configuration were addressed - if not, remember to keep them in mind if you see more problems as node count increases.
Not at the moment, but surely if there would be any problems that arise, I will check them. Thank you
Closing as there is no more problems to solve. Please raise a new issue ticket if anything new appears.
Hello, guys I am have a problem. I can not connect a node and a border router with a spirit1 radio. I have a nucleo boards with stm F411, L152(for nodes) and F429(for BorderRouter) But I can not find the working configurations for connecting any this modules. On the NUCLEO_F429ZI with NUCLEO Spirit1 I made changes with resistors R4 to R7 and SB121 to SB122. I do not understand what am I doing wrong? Can you send me really working .json files for BorderRouter on the NUCLEO_F429ZI and nodes on the any NUCLEO_L152 or NUCLEO_F411 boards? (6LoWPAN or thread configures)
Tanks
@jWladimir this repository is only for the Client-application. Please check the border-router repository here: https://github.com/ARMmbed/nanostack-border-router
Also, please open a new issue if something does not work.
Border router application already has example config for F429ZI and Spirit RF module. https://github.com/ARMmbed/nanostack-border-router/blob/master/configs/6lowpan_Spirit1_RF.json
Also the example configuration for 6LoWPAN already has Spirit RF module enabled: https://github.com/ARMmbed/mbed-os-example-client/blob/master/configs/mesh_6lowpan_subg.json#L9
For debugging connectivity problems, please first use mbed-os-example-mesh-minimal application. Once the connectivity is proven to work, continue to use the Client example. In any issues, please raise a new ticket. Thanks.
Description
With seven or more clients connected to the mbed Device Connector some of them are not listed temporally or disappear until I reset the client.
We are using mbed-os-example-client for 10 boards, 3 of them are NUCLEO_F429ZI+X-NUCLEO-IDS01A4 boards and the others are sensor-node boards (it's a new kind of board, we are developing on it, @MarceloSalazar knows it). The border router uses the nanostack-border-route repository and it is a NUCLEO_F429ZI+X-NUCLEO-IDS01A4, it uses a ethernet cable connected to the internet router (with enabled 6to4 tunneling). The mesh is via Spirit, we have worked with Wolfgang (@betzw) in order to have the spirit driver stable.
The NUCLEO_F429ZI boards use the lastest commit of the repositories, the sensor-node board come from the versions:
mbed-os-sensor-node (5f27acc88541) |- easy-connect (6fb5842becae) | |- atmel-rf-driver (57f22763f4d3) | |- esp8266-driver (4ed87bf7fe37) | |
- ESP8266\ATParser (269f14532b98) | |- mcr20a-rf-driver (d8810e105d7d) |
- stm-spirit1-rf-driver (ac7a4f477222) |- mbed-client (f8f0fc8b9321) | |- mbed-client-c (c739b8cbcc57) | |- mbed-client-classic (f673b8b60779) |- mbed-client-mbed-tls (7e1b6d815038) |- mbed-os (ed4febefdede)
- pal (4e46c0ea8706)Every client has its security.h file and a different MAC address. We have done this test:
here you can read the trace of the border router: https://pastebin.com/ti8U3HgS
From the sniffer seems that the lost clients (I mean who disappear from the mbed connector list) continue to communicate with the border router. We don't have information about how the nanostack works so we have problem to get a better idea what is going on.
To try to understand what happen we have:
Our goal is to have more than 10 boards connected to the mbed Device Connector. What can we do?