I'm a new user of dd-wrt and ran into this issue with bonjour devices being unavailable on my Asus N66U. For whatever it's worth to others trying to find a solution, I've followed through some of the comments and downgraded to build 33006 and now everything is working. I'm not too worried about the Krack bug in my tiny neighborhood.
...ran into this issue with bonjour devices being unavailable on my Asus N66U. ...I've followed through some of the comments and downgraded to build 33006 and now everything is working....
Did you use the K2.6 or the K3? _________________ R6250 with fan on; wifi off
R6300.1 mips DD-WRT 42617 Giga AP
WNR3500Lv2 DD-WRT 33525 K3 Giga
E3000 5ghz multicast AP DD-WRT 33525 K2.6
WRT54GSv2 long range AP HyperWRT 15
2 WR841Nv9 DD-WRT 33006 AP
K3. Specifically I downgraded to dd-wrt.v24-33006_NEWD-2_K3.x_mega_RT-N66U.trx
I did notice your comments about 33525 being usable on your netgear as well but I just went with the earlier build since it was confirmed to work on an asus. I would consider testing other builds, but my wife has been frustrated enough lately with our network and now that everythings working I may leave things as is.
K3. Specifically I downgraded to dd-wrt.v24-33006_NEWD-2_K3.x_mega_RT-N66U.trx
I did notice your comments about 33525 being usable on your netgear as well but I just went with the earlier build since it was confirmed to work on an asus. I would consider testing other builds, but my wife has been frustrated enough lately with our network and now that everythings working I may leave things as is.
33006.k3 and 33525.k3 are extremely similar; so, if it is working now, I suggest to leave it be.
33525.k3 didn't work on my E4200, and it did an incomplete job on my r6300v1 (brother to your asus) until I turned on IGMP from the network tab. So, I'm thankful to know that 33006.k3 provides an alternative.
Posted: Sun Mar 17, 2019 8:16 Post subject: chromecast on 2.44 laptop 5ghz, not able to configure
discerr wrote:
I'm also running 34311 on an RT-AC66U, and I can confirm that AP isolation appears to be occurring; I can't cast to my Chromecast (on my 2.4GHz AP) from my laptop (on my 5GHz AP). If my laptop connects to my 2.4GHz network, casting works fine.
Actually thats by design, these days. the Google Home App must be conencted to the same AP, and the same Freq, per the docs.
Joined: 08 May 2018 Posts: 14125 Location: Texas, USA
Posted: Sun Mar 17, 2019 12:02 Post subject: Re: chromecast on 2.44 laptop 5ghz, not able to configure
sunnytoes wrote:
discerr wrote:
I'm also running 34311 on an RT-AC66U, and I can confirm that AP isolation appears to be occurring; I can't cast to my Chromecast (on my 2.4GHz AP) from my laptop (on my 5GHz AP). If my laptop connects to my 2.4GHz network, casting works fine.
Actually thats by design, these days. the Google Home App must be connected to the same AP, and the same Freq, per the docs.
That clarifies some things. But I think there was some intention to 'fix' that in DD-WRT, or maybe the gtk and KRACK fixes broke the intended functionality of the manufacturer by design. I can't speculate on that, but.
Joined: 29 Nov 2013 Posts: 36 Location: Düsseldorf, Germany
Posted: Sun Mar 17, 2019 21:23 Post subject: iptables
Actually, you need to use -v to see, which interfaces are affected:
Code:
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
5766 993K ACCEPT 0 -- any any anywhere anywhere state RELATED,ESTABLISHED
15 5042 ACCEPT udp -- vlan2 any anywhere anywhere udp spt:bootps dpt:bootpc
0 0 DROP udp -- vlan2 any anywhere anywhere udp dpt:route
0 0 DROP udp -- br0 any anywhere anywhere udp dpt:route
0 0 ACCEPT udp -- any any anywhere anywhere udp dpt:route
650 46143 ACCEPT 0 -- br0 any anywhere anywhere
0 0 DROP icmp -- vlan2 any anywhere anywhere
0 0 DROP igmp -- any any anywhere anywhere
9 629 ACCEPT 0 -- lo any anywhere anywhere state NEW
0 0 ACCEPT 0 -- br0 any anywhere anywhere state NEW
247 25414 DROP 0 -- any any anywhere anywhere
Posted: Thu Apr 04, 2019 2:04 Post subject: Re: iptables
knob-creek wrote:
Actually, you need to use -v to see, which interfaces are affected:
Code:
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
5766 993K ACCEPT 0 -- any any anywhere anywhere state RELATED,ESTABLISHED
15 5042 ACCEPT udp -- vlan2 any anywhere anywhere udp spt:bootps dpt:bootpc
0 0 DROP udp -- vlan2 any anywhere anywhere udp dpt:route
0 0 DROP udp -- br0 any anywhere anywhere udp dpt:route
0 0 ACCEPT udp -- any any anywhere anywhere udp dpt:route
650 46143 ACCEPT 0 -- br0 any anywhere anywhere
0 0 DROP icmp -- vlan2 any anywhere anywhere
0 0 DROP igmp -- any any anywhere anywhere
9 629 ACCEPT 0 -- lo any anywhere anywhere state NEW
0 0 ACCEPT 0 -- br0 any anywhere anywhere state NEW
247 25414 DROP 0 -- any any anywhere anywhere
Call me dense or lazy. plz. But tell me what this means!
Joined: 08 May 2018 Posts: 14125 Location: Texas, USA
Posted: Thu Apr 04, 2019 15:21 Post subject:
I'm wondering now if this is all tied into the 'broken' SFE you mentioned in the other thread @knob-creek. I haven't tested disabling SFE yet, but I've also turned off my 2.4GHz radio since it's not being used, and to see if it was culprit to other wi-fi issues.
Happening to me as well on a Linksys WRT1200AC V2 (Marvell-based device, so it seems it's not BCM-specific) running 39296 build.
Tried disabling SFE - did not help.
What's strange is that sometimes (for a reboot, or two) everything works and sometimes the bug shows up.
Joined: 29 Nov 2013 Posts: 36 Location: Düsseldorf, Germany
Posted: Sun Apr 07, 2019 21:49 Post subject:
kernel-panic69 wrote:
I'm wondering now if this is all tied into the 'broken' SFE you mentioned in the other thread @knob-creek.
As already mentioned in the other thread: After disabling SFE first everything seemed to work much better. But after some time, the known issues were back.
The situation is exactly as described in ticket 6556. Sometimes, connections blocked (e. g. to my cell phone, from which i cannot send pings) are even working again spontaneously.
I have now enabled logging to a PI connected by wire. Except for some messages like
Quote:
Apr 7 21:14:30 dark-knight kernel: br0: received packet on eth1 with own address as source address
The content of the log looks harmless.
Except that i had to filter out huge amounts (10 MB/min!) of totally weird messages regarding some "timer":