It says to disable the firewall and then check filter multicast. However, this seems impossible because I can either have both multicast filtering and the firewall enabled or both disabled, not the firewall disabled and multicast filtering enabled. It seems to work fine without multicast filtering enabled though, you wouldn't be reading this if it wasn't. Sometimes it won't load a website and gives a DNS error and i have to refresh to get it to load but it also did this on older versions of dd-wrt where I could disable the firewall and enable multicast filtering so i dont think thats the issue.
What the router provides is an IP firewall, which means it's only effective when routing is taking place on the router (e.g., LAN<->WAN traffic). But in any bridged configuration, there is NO WAN, so the IP firewall has no effect on LAN to LAN traffic. Those devices communicate directly with one another over ethernet without the need for routing. As a result, it makes no difference if you enable or disable the firewall, it's NOT going to work. Nor are any of the various WAN filters going to work either. Once you've configured the router in a bridged configuration, the router becomes nothing more than a wireless switch, and any and all firewall settings become irrelevant.
This is why you can't take the various wikis as gospel. Most are written by other users who sometimes don't understand certain issues, and therefore make erroneous suggestions. Notice it also tells you to change from Gateway to Router mode. Yet another example of something completely irrelevant. This is only meaningful in a routed configuration (i.e., active WAN), since it determines whether NAT should or shouldn't be enabled for the WAN.
What the router provides is an IP firewall, which means it's only effective when routing is taking place on the router (e.g., LAN<->WAN traffic). But in any bridged configuration, there is NO WAN, so the IP firewall has no effect on LAN to LAN traffic. Those devices communicate directly with one another over ethernet without the need for routing. As a result, it makes no difference if you enable or disable the firewall, it's NOT going to work. Nor are any of the various WAN filters going to work either. Once you've configured the router in a bridged configuration, the router becomes nothing more than a wireless switch, and any and all firewall settings become irrelevant.
This is why you can't take the various wikis as gospel. Most are written by other users who sometimes don't understand certain issues, and therefore make erroneous suggestions. Notice it also tells you to change from Gateway to Router mode. Yet another example of something completely irrelevant. This is only meaningful in a routed configuration (i.e., active WAN), since it determines whether NAT should or shouldn't be enabled for the WAN.
Fortunately, most of these erroneous suggestions are benign. They have no negative effects whether or not implemented. But it can give the false impression that it *does* matter. And that's the problem here.
I thought it was weird and had no effect but thought whoever wrote the article might know something i don't. Thank you.
Joined: 08 May 2018 Posts: 14223 Location: Texas, USA
Posted: Mon Jan 10, 2022 12:33 Post subject:
Check output of nvram show | grep filter_multicast via telnet / ssh. If it is 1, then it's a webUI anomaly and I am not sure why it doesn't display like it used to other than the firewall is selected disabled.
Check output of nvram show | grep filter_multicast via telnet / ssh. If it is 1, then it's a webUI anomaly and I am not sure why it doesn't display like it used to other than the firewall is selected disabled.
Again, if people continue to have issues handling these fake bridge modes, they will be removed as options.
The output of "nvram show | grep filter_multicast" just gives me the size of something in bytes and not a 0 or 1
I think the reason client bridge drops for me sometimes is more than likely an ARP related problem. It's probably just inherent to how the client bridge hack works. I tried the clicking apply settings on the advanced routing page fix from the post you linked and that seems to have fixed the dropping issue.
I ended up giving up, I was still having dropping issues. Tried every DHCP/ARP related fix I could find with no luck. I reflashed the stock TP-Link firmware and setup a WDS bridge. It now works flawlessly. So sad because I hate the stock firmware but since it's not internet facing it's fine.
Looks like the nvram variable name changed (or was wrongly quoted to begin with?):
Code:
block_multicast=1
Check that. If clicking the save button after checking it and checking it again and again ad infinitum don't werk, then do:
Code:
nvram set block_multicast=1
nvram commit
reboot
Problem solved. _________________ "The woods are lovely, dark and deep,
But I have promises to keep,
And miles to go before I sleep,
And miles to go before I sleep." - Robert Frost
"I am one of the noticeable ones - notice me" - Dale Frances McKenzie Bozzio
Joined: 13 Aug 2013 Posts: 6868 Location: Romerike, Norway
Posted: Fri Jul 08, 2022 6:42 Post subject:
The C7 is an Atheros.
It do have an Option on the wifi "Multicast to Unicast". Multicast will be converted to Unicast before sent over wifi to avoid the Multicast speed limit with wifi
These modes do not have functional arp or multicast. Also, how do you plan to use the WAN port as part of the switch? It would be nice to have the details of proof to not disable the firewall or change operating mode, since this is part of the wan disable function, no? _________________ "The woods are lovely, dark and deep,
But I have promises to keep,
And miles to go before I sleep,
And miles to go before I sleep." - Robert Frost
"I am one of the noticeable ones - notice me" - Dale Frances McKenzie Bozzio
