Apparently there’s an RC6 version out. I just contacted support, ill pass on the firmware when I get it. Im using the Netpower 7R
This worked for me FYI
Disabling “Add Information Option”
I know this is an old thread, but I guess I have quite similiar issues so maybe someone could help.
This is the network setup I have done so far:
- There are several DHCP-servers running on my router, relevant for this topic are
- 192.168.21.1 on VID 20
- 192.168.41.1 on VID 40
- 192.168.61.1 on VID 60
- Uplink from CSS610 to TP-Link SX3008F is done via FS.com SFP+ module and OM3 MMF fibre
- downlinks to
- access point OpenWrt BPi-R4 via FS.com DAC
- 3 client devices and 3 IoT devices via Cat.6A copper
- I can reach the CSS610 via 192.168.21.8
- I have configured the following within the CSS610 web interface:
- I cannot reach any of the client devices
- the client devices cannot reach the network (laptop/printer/etc are currently turned off, so not showing up in picture above)
- I followed the advice from above to uncheck the box “Add Information Option”, but that didn’t change anything
Any idea on how to proceed here? I tried to change the VLAN mode or the VLAN Receive options, but no success so far…
From where?
From where?
Which network?
Details matter.
In your diagram it says on the trunk links "tagged traffic only", but you are specifing pvid as 20. That may or may not cause a problem based on the equipment in use. But if you are sure that vlan 20 is represented with tagged traffic, then you should set the pvid (on on CSS default vlan) to some vlan you are not using (even 1).
But this looks odd to me
Following from CSS610 series Manual
Specifically this section VLAN and VLANs
The section has examples. I suggest reviewing them.
- I could reach the CSS610 via its IP 192.168.21.8 via a PC connected to 192.168.21.0/24 network (my PC connected to a lan-port of the router)
- I couldn’t reach the client devices by their IPs (e.g. 192.168.41.100 for one of the Shelly IoT sensor) when being connected to 192.168.41.0/24 network (my PC connected to a lan-port of the router); (similiar to what happened when I tried to access the OpenWrt access point via 192.168.21.9 via a PC connected to 192.168.21.0/24 network)
- When I was connected to the Shelly, they recognized a connected cable, but by no means were able to send/receive any traffic via that cable (similiar to what happens to a laptop client, which was expected to get DHCP-offers in 192.168.61.0/24 range)
Thanks alot, this was my issue - I completely overlooked these checkboxes. After unchecking them, the traffic to/from the client devices with untagged-configuration is now flowing as expected!
What does not yet work is the tagged traffic to the AP_Buero device. I will debugg that further tomorrow.
Because the two trunk ports are configured identially, you should be able to swap the SFP/DAC modules and verify that everything works the same as before, i.e. you could swap connections (the Switch_Server and AP_Buero ports). If things work the same, then that seems to eliminate the CSS as the cause of the problem. You already know that Switch_Server is working. So if swapping causes access to the other devices on the CSS610 to stop working, then you need to look at the SFP or possibly other settings on those ports. But everything you have shown shows those two ports configured identically, so my guess is that it is something on the openWrt config on AP_Buero.
Alternatively, when the network isn't being used, take AP_Buero over to where the CSS is, and pull the SFP from the OpenWrt Router (not AP) and plug it directly into the OpenWrt AP_Buero. Can devices now connect via AP_Buero? If not, it definately has nothing to do with the CSS610, so fix the issue with the AP_Buero portion first.
If you click on the CSS610 Hosts tab, do you see any mac addresses listed under the AP_Buero port? The Host tab lets you view the MAC/vlan address table in the switch. So you should see at least the AP_Buero BPI-R4's MAC address.
I completely reconfigured the AP from scratch as there have been some weird other issues - and now it is recognized.
Thanks alot for your help!