Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button (red circle; this works best in the 'Markdown' composer view in the blue oval):
Remember to redact passwords, VPN keys, MAC addresses and any public IP addresses you may have:
This is information you had not previously mentioned...
At a basic level, it is not the router -- specifically not the routing/firewall engines of the main router -- because you have a flat (single subnet) network. Connections within your network are all made at Layer 2 which does not involve the firewall/routing services.
But now that we know there are multiple APs (and maybe switches)... Let's start with a network topology diagram -- please show all of your network infrastructure devices and the relative position of the NAS and computer at issue, and be sure to indicate which links are wired vs wireless.
Eveything started when i simply wanted to use the Cudy via LAN.
The problem occurrerd there first, from my desktop i wasnt able to ping the devices on the flint lan but my wifi phone could, so i said wait maybe the cudy is badly configued and i've removed it but didnt resolve, then i rebooted the flint and it was fixed by connecting on the same lan switch
From there i decided to try 802.11s mesh and when i was setting it up the wired devices went dark again. Now I've set up the mesh and rebooted the flint and i can ping everything.
Is there a log that i can look through? because this feels like something really sporadic and given my setup is quite simple i dont see an issue in my config
Without information about the physical topology of your network, it's hard to know what is happening. But, for example, if you have wired connectivity between your APs, you do not want mesh because it will cause network loops which will cause the network to go down in part or in whole. Mesh is specifically about wireless backhaul and should generally be used only when wired connectivity between the APs is not an option.
Yes, that's why the topology can be simply seen as Flint with 2 lan devices. Eveything else were tests i did. Do you think that those tests were making the connection of the wired devices fail? Why not the wifi? I will monitor some more to see whether it happens again
It is not that simple if there are other infrastructure devices (I.e. switches, APs) involved.
Are the NAS and computer both physically connected to the Flint's Ethernet ports?
If you unplug and/or physically turn off the other APs/switches such that the Flint is the only network infrastructure devices, do the NAS and computer talk to each other?
So to be completely clear about the current state:
There are only two things connected to the Flint Ethernet ports (not counting the upstream/wan)
The computer and the NAS
There are no additional APs (mesh or otherwise) that are powered on?
There are no switches or other devices connected anywhere
The router itself can reach both the NAS and the computer
The computer cannot reach the NAS and vice versa
Is that all correct?
What methods are you using to try to test connectivity between the router and the computer/NAS and between the computer and the NAS?
ping? ssh? something else?
I would highly recommend checking both the docker configuration and the host's config... a misconfiguration in the network and/or host/docker firewalls could cause the behaviors you're seeing.
Alternatively, you could unplug the NAS and plug in another host on the same physical port... something like a pi running a fresh copy of RaspberryPi OS would be totally fine, or really any normal Linux distro. Then run your tests again... I suspect the problem is your docker/host config, not the router.
As I said wifi devices had no issue, so the problems are not in the Dockers especially because the services are also exposed on the internet and they were accessibile via mobile
Yeah... but still, none of it makes any sense in my mind. Your network topology is pretty simple with respect to the ports on the router -- they're all part of the same bridge and assigned to the same network interface. This traffic should traverse transparently insofar as the routing/firewall engines don't get involved as the switch chip should handle everything.
With that in mind, could you try connecting two entirely different devices.... ideally two simple Linux boxes (could be Pis) to the respective ports and then test to see if they are able to connect to each other?
