Currently on an Archer C60 and CPE210 with snapshots I get about 20 Mbps between them using 802.11s. With WDS 60 Mbps approx.
1 Like
Yes, the source address of the DHCPv6 reply was definitely that of the mesh node.
After stopping (and disabling) the services, the DNSv6 entry is removed from the client connections, and regular DNS access is restored.
I would like, however, to achieve a clean configuration, and a clean interaction of that configuration with the regular operation of the device, without relying on any extra steps carried out through the backdoor.
Do you have any suggestions for finding the true problem?
Thanks for your help.
The true problem is that you did not configure the device correctly in the first place.
The default configuration of OpenWrt is to work as an ip router with dhcp and dns for its clients.
As mentioned elsewhere in this thread, the first step in configuring a mesh node is to change the default OpenWrt configuration to make the device a Wireless Access Point.
A good starting point for beginners is the wiki article suggested by @elan ie:
I really do not know what you mean by this. You get what you configure.
If you want a dedicated firmware for a mesh node, you can use the Imagebuilder, adding in all the configuration steps required for your particular application. Understanding all the requirements is required and the best way to get that understanding is to do it manually first.
1 Like
I have not tried those devices, but as you say, it all depends on the device and its resources.
For both 802.11s and WDS, the backhaul and AP traffic are contending for access "on the air" so the expected traffic rate is cut in half.
With a channel width of 20MHz, the theoretical throughput is 150Mb/s, so the best you can get will be 75Mb/s. In practice your 60Mb/s sounds about right.
Using a pair of GL-MT300N-V2 devices, I do indeed get ~60Mb/s, but for both WDS and 802.11s. This fits in with your findings for resource constrained devices.
2 Likes
If so, I am asking for help identifying the specific, incorrect configuration.
As indicated earlier, I believe I have followed these steps. Have you found a specific omission?
Configuration was to disable DHCP servers on the interfaces. As I would understand, and has been implied by the referenced articles and others, disabling the unneeded services in the sense of running system processes is an optional step that may optimize resource utilization, but not necessary simply to prevent any DHCP requests from being processed by nodes connected to the device.
That is, if the DHCP service is running as a system process, but not attached to any interfaces (by their configuration), then the device may be considered correctly configured as an AP. Do I misunderstand?
Sorry, I don't understand the relevance of this suggestion.
That wiki guide is just a guide for beginners - nothing more. It is a guide to help in setting up a Wireless AP. It allows you study how it all fits together and learn more in depth. It is not a definitive set of instructions for creating wireless access points on any hardware.
I have told you already how to fix your incorrect mesh node configuration, and you have tested it and found that it works. I am not sure what more you want.
Your comment, "extra steps through the backdoor", implies you do not want to be bothered with configuring multiple devices. Imagebuilder allows you co create your own pre-configured firmware - hence the relevance of my suggestion.
2 Likes
I understand completely. I was responding to your suggestion that I review it.
This issue is that configuration through Luci makes possible, in general, detaching the DHCP services from the interfaces without stopping them as processes on the system. Such is my objective. Frustration realizing it points to some deeper problem or omission.
So far, the only working solution has been terminating the processes that provide the services. I would like at least to ensure that detaching the services works correctly, whether or not they are also removed from the list of active system services.
I see.
What I had meant was understanding why the expectation has not been achieved of being able to detach the services from the interfaces without stopping them at a level of system processes.
Terminating and disabling the services is not a workaround for a problem. It is a fundamental requirement of a working configuration.
You can stop and disable services in Luci if you are worrying about using the command line in a terminal.
Your frustration is due entirely to your lack of in depth knowledge. I do not say this in a bad way as you are obviously very interested and keen to learn. Luci is simply a GUI interface that constructs and runs commands, the very same commands you could use in a terminal. The best way of learning and developing a deeper understanding is to look in detail at the /etc/config files that Luci works with using numerous libraries and utilities like the uci command (where Luci gets its name).
2 Likes
If the objective is to detach the service from the interface without terminating it, then terminating it is a workaround. Detaching has been documented as a standard approach (see below).
Consider the possibility that I may wish to use the service in the future, but not for the particular interface. The only solution is to detach it from the interface without disabling it.
More deeply, if detaching is supported by a series of steps, and I believe I followed those steps, but have not achieved detachment, then either I misunderstand the process, or the system is not functioning as expected generally.
I wish to understand which is the case, and why.
Yes, I know. The main issue is not web versus shell access, but disabling versus detaching the service.
Yes, I am still learning, but the essential premise is supported by documents.
Consider the following two passages from the document referenced earlier:
-
Use the main router for DHCP.
Ensure the Ignore interface checkbox is checked.
-
To save resources on the wireless AP router, disable some now unneeded services. Navigate to System → Startup.
For a more permanent fix see Disable Daemons Persistently.
Thus, we see that either is sufficient, with the latter (2) explained as being a more comprehensive approach, which may save resources, but also being more limiting, compared to the former (1), by having global scope for the device, not simply local scope for some interface.
You have completely lost track of what you are trying to achieve. Your objective is to configure a simple non ip routing mesh node. A non ip routing mesh node will never need to provide DHCP services. So the logical way to proceed is to disable the services.
Re-enable it and re-attach to the interface if that becomes a future requirement.
You are blindly following a series of steps with no understanding of what is going on.
The problem you brought up is that ipv6 clients are receiving an ipv6 dhcp configuration.
They are doing this because the mesh node is configured as an ipv6 dhcp server.
Apparently not.
It is very easy to blame everything but your own incorrect configuration. I suggest you check it again. Why not just disable the service to make sure? /s
2 Likes
Part of my objective is to understand how my devices are operating, at least with respect to the very simple provisioning I have chosen to undertake.
I think not. I think I understand each step, and its significance. I may well be misunderstanding some details without realizing the mistake, in which case I would be grateful to receive any specific clarification that would resolve my misunderstanding.
You have misunderstood me. I am not dismissing that the configuration may be incorrect, or blaming another cause. I am asking for help isolating the issue, wherever it may be, in the configuration, or elsewhere.
1 Like
You ask for help, are shown what the problem is, test that the corrected configuration works, yet continue to ask the same questions over and over. I am not sure what the implications of this are but whether you realise it or not you now have all the information available to you to go back to your other post and rewrite your "Guide".
But maybe you should first do more of your own research and testing to clarify your understanding.
2 Likes
I thank you for your assistance so far, which has been greatly helpful and without which I would remain under more than a few misapprehensions.
The record shows I have attempted my own research, and am acquiring incrementally more complete and accurate understanding. At the present moment, the point where I have hit a wall is resolving why the attempt has failed to disable (i.e. ignore, detach, etc.) DHCPv6 in the interface configuration. If you are able to lend further assistance, I would be grateful.
Your current line of commentary, on subjects such as my broader objective or method, is not helpful. Thanks.
1 Like
When "detaching from the interface", have you checked your config files to see if the ipv6 server is disabled? I guess not.
Assuming I wanted to keep the ipv6 dhcp daemon running, I would "detach" with the following commands:
uci set dhcp.lan.dhcpv6='disabled'
uci commit dhcp
service odhcpd restart
I would expect Luci to run the same commands. However, for a simple mesh node there is no requirement to have DHCP running, and if it is running it is at best a waste of resources and at worst might break something (as you have found out).
2 Likes
Thanks for the reply.
I queried dhcp.lan.dhcpv6 through the shell command as you suggested, and found the value showing server. I never changed it using a shell command.
After I had set the interface protocol to "DHCP client" in Luci, the settings for DHCP server disappeared. I would understand this interface behavior to suggest that a DHCP server is automatically removed from any interface configured as a DHCP client. Such mapping would be entirely sensible, since it would be quite irregular for an interface to function both as a DHCP server and client.
I think it is generally confusing that the interface would continue to operate with a DHCP server attached even while it is configured as a DHCP client, especially with no options shown in the graphical interface to remove the server.
I would expect the interface is not designed with this intention generally, which leads me to wonder whether some other conflict is contributing the observed behavior.
By the way, please keep the tone of the conversation constructive, avoiding snarkiness in any future contributions. Thanks.
1 Like
You have not changed it, so it is still defaulting to being an enabled server.
It took me a bit less than 60 seconds to "research" this to find that Luci appears to have a bug. It does not set the ipv6 server to disabled when requested, instead it just deletes the line from the config, resulting in odhcpd defaulting to server mode.
Your unwillingness to even look outside of the Luci UI or do any proper research on this is what has greatly tried my patience. I apologise for any snarkiness.
I suggest you read up on how OpenWrt manages configurations, how this is related to Luci, what the difference is between ipv4 dhcp and ipv6 dhcp.
You will then be in a position to report this Luci problem as a probable bug:
2 Likes
If I had to choose between your apologizing versus stopping, I would choose the latter. Instead, you continue. In contrast to sharing accurate and comprehensive technical knowledge as you had done earlier in the discussion, your ongoing judgments, appraisals, and critiques of me are not helpful, to me, or to the community.
What does it even mean when you refer to my "unwillingness to look outside Luci"? A picture emerges that you are trying to understand a good deal about me that is not necessary for this discussion. It is clear to me that your methods toward these ends are not leading you to accurate conclusions.
Instead of bragging about how quickly you found a reference, why not simply share it, for the benefit of all who may read this exchange, as well as me.
Above you indicated that it has been reported already, and is a known bug, that Luci fails to handle the DHCPv6 case as it does the v4 case.
Before those statements, in an earlier post, you criticized me for suggesting that any kind of flaw in the system was behind my observations.
Please, if you have useful information you wish to contribute, on the technical subject matter, then do so, but without the additional personal commentary. Thanks.
1 Like
There is more to research than just reading what other people have done.
My research on this today consisted of experimental testing to identify the cause (and it did only take ~60 seconds). Basically it consisted of checking the config files before and after disabling in Luci.
The actions I performed were as follows:
- Check the dhcp config file for dhcpv6 enabled - it was
- Use Luci to disable at the interface
- Checked the config file and found the entire line had been deleted
- Checked odhcpd was still serving ipv6 dhcp on the interface - it was
Conclusion:
- Luci does not set to disabled
- Luci removes the entire line from the config.
- odhcpd defaults to enabled if a config does not exist
- This appears to be a bug in Luci
I did not "find a reference". Instead I looked at the actual issue and immediately found the problem. Something you could have done also. I did strongly suggest that you look, but you chose not to. I was so annoyed at feeling I had wasted so much time on this that I had to look myself.
At no time have I indicated it has been reported already - on the contrary, I suggested that you report it.
As far as I am aware it is not a known bug, until now that is. Probably no-one has ever noticed as it is quite an edge case. I have certainly not noticed as I only use Luci in exceptional circumstances, using the command line options directly as usually I end up creating an installable image with Imagebuilder.
2 Likes
Perhaps mostly people set protocol to static address and then disable DHCP server:
It is a pity about the LuCi bug - sorry about that @brainchild.
Is this enough to explain why it is an edge case? Else I wonder why it has not been noticed yet.
Would the static address + disabling DHCP server be an option, or perhaps you will just manually configure now?
2 Likes
I believe I did too, but lacked the broader context of the system and the community to distinguish the important observations or to draw reliable inferences. The need for such context is an appropriate reason for someone in my position seeking information as I had done from someone in yours.
Yes, you conducted a specific experiment, and drew from the observations specific conclusions, as you were able to do by carrying into the matter your broader knowledge.
I would have performed the mechanics of any test and reported back to you, and in fact had every intention to follow such a scheme, if you had suggested any. The responses, however, rather diverged into broad personal appraisals and critiques of my supposed objectives or motives.
I am not aware that you made any suggestion specific enough to have been actionable, though I may have missed it. Broadly, I noticed that the tone degraded into a judgmental personal diatribe. If you had made a suggestion that I unfortunately had missed, surely there were opportunities to point to my innocent omission.
I understand now why you felt as you did, but I am thinking that your frustration has been no more a consequence of my choices than of your own evaluation of them. Trying to learn my perspective, and to address my questions through it, might have carried the conversation more smoothly.
Yes, it is a sensible line of speculation, without doubt, and your mentioning it brings us to the crux of the issue. Only someone who has enough relevant background in the subject matter is competent to eliminate other obvious possibilities, and to establish this particular one with appropriate credibility.
Much of my engagement in the recent part of the discussion has been informed by a sensibility to avoid adopting a hasty conclusion.
If I had followed your suggestion of reporting a bug, before having credible backing that I had uncovered one, I would have been showed a great hubris, posting remarks to the issue tracker of the following tone:
I know virtually nothing about the system you developed, its expected behavior or its basic operation, but I do know it's broken, and I expect you to fix it.
Worse, if it would have been that my unmet expectations about the the behavior followed from my own ignorance or oversight, and yet I had hastily assumed it from a flaw in the system, I would have blocked myself from finding a productive resolution, even as one would have been available.
Broadly, overlaying my behavior with your background has not helped you understand my thinking.
1 Like