Joined: 08 May 2018 Posts: 14207 Location: Texas, USA
Posted: Thu Jul 23, 2020 13:10 Post subject: New Build - 07-23-2020-r43904
[WARNING]: This thread is only for feedback on this beta release for developers and the community's benefit.
DO NOT flash this beta release unless you understand the risks involved and specific device recovery methods.
Avoid discussions! Create threads for questions, general problems or use search; this thread is not for support.
Please list router model & revision, operating & wireless mode(s) and exact filename/firmware image flashed.
Notes:
• CVE-2019-14899 VPN fix (applicability depends on VPN setup) and GUI toggle. 6920, 6928, 6931, 6932 (WIP 7040)
• In-kernel Samba has been implemented this year and default min/max versions have changed 6954, 6957, with WSD support.
• VAP issue is fixed! For any Wireless Mode, create a VAP and both ath0/ath1 should now function properly.
• Local DNS option removed from Services->DNSMasq in changesets 43080 and 43081; ref: #7092
• DHCP and DNS help (English) updated in 43083; ref: #7091
• WireGuard 1.0.20200712: PBR, Kill Switch, Inbound Firewall, Naming of Peers, Status, Key, Guides. Thanks egc!
Issues:
• There may be remaining issues for Samba (for example NTFS), with frequent updates.
Important:
• If reporting issues provide applicable info: 'dmesg', 'cat /tmp/var/log/messages', syslog/serial output, strace etc.
• For firewall issues provide 'iptables -L', 'iptables -t nat -L' and the /tmp/.ipt file.
• Search existing SVN tickets before opening a new one. Before reporting, reset and manually setup (no nvram backup).
• Be sure to include operating and wireless modes (Gateway, AP, CB, etc.) along with relevant configuration information.
Joined: 08 May 2018 Posts: 14207 Location: Texas, USA
Posted: Thu Jul 23, 2020 17:27 Post subject:
There are a lot of the TP-Link TL-WR*4*N* routers that are probably lacking 100% proper identification. We could probably spend a lot of time tracking this down and fixing it. My TL-WR940Nv3 is identified as a TL-WR941N(D)v6... there is probably some identifier that separates the two as they are identical, except one is re-branded as another model. _________________ "Life is but a fleeting moment, a vapor that vanishes quickly; All is vanity"
Contribute To DD-WRT Pogo - A minimal level of ability is expected and needed... DD-WRT Releases 2023 (PolitePol)
DD-WRT Releases 2023 (RSS Everything)
----------------------
Linux User #377467 counter.li.org / linuxcounter.net
Netgear WNDR3700 V4
DD-WRT v3.0-r43904 std (07/23/20)
Linux 3.18.140-d5 #84921 Thu Jul 23 04:55:09 +04 2020 mips
GUI install over r43886
switch / samba share ext4 / OVPN server
all worky fine
#
Linksys EA8500
DD-WRT v3.0-r43904 std (07/23/20)
Linux 4.9.231-rc1 #603 SMP Tue Jul 21 20:21:06 +03 2020 armv7l
GUI install over r43899
switch / VLAN / samba share ext4 / OVPN server
tis all worky good
Not gonna install on main EA8500 cause it's kinda busy and its r43899 is the same nevermind anyways
Router/Version: Netgear R7800
Firmware: DD-WRT v3.0-r43904 std (07/23/20)
Kernel: Linux 4.9.231-rc1 #603 SMP Tue Jul 21 20:21:06 +03 2020 armv7l
Mode: Gateway + AP
Reset: No
Previous: DD-WRT v3.0-r43886
Using: 2.4 GHz, 5.0 GHz, IPv4, DNSMasq, USB, NTP TimeSync, Samba, QoS
Status: Working Fine
Thank you BrainSlayer for your continued work!
Samba seems stable, I was unable to break it so far. Thanks!!
I have some quirks with QoS (HSFC/CAKE) after hitting the "Apply Settings" button on Setup->Basic Setup (without changing anything). Down Bufferbloat seems uncontrolled, but up is fine. Syslog shows IMQ being loaded successfully. I adjusted my QoS numbers but it still happens.
Hitting "Apply Settings" on "NAT/QoS"->QoS. Fixes it every time.
Bad: http://www.dslreports.com/speedtest/64965716
Good: http://www.dslreports.com/speedtest/64965760
Joined: 05 Oct 2008 Posts: 666 Location: Helsinki, Finland / nr. Alkmaar, Netherlands
Posted: Thu Jul 23, 2020 20:05 Post subject:
R7800 now on build 43904.
The IPv6 test at https://ipv6-test.com/
finds a problem with ICMP.
I tried to enable and disable the Multicast filter and rebooting the router, but to no avail.
Whatever caused the recent flipping of Filter Multicast, may have come back to bite us again.
Next I'll revert to an earlier build.
A little while later:
Downgraded as far as 43800 skipping some of the intermediate builds, but no change. ICMP doesn't work.
Upgraded back to 43904 with reset and then restored saved settings. All to no avail. The test comes out 18/20 where it used to be 20/20 and it's due to ICMP not working (Not Tested as per the test result in grey).
Joined: 21 Nov 2013 Posts: 65 Location: Cathedral City, CA, USA
Posted: Fri Jul 24, 2020 0:09 Post subject:
ArjenR49 wrote:
R7800 now on build 43904.
The IPv6 test at https://ipv6-test.com/
finds a problem with ICMP.
I tried to enable and disable the Multicast filter and rebooting the router, but to no avail.
Whatever caused the recent flipping of Filter Multicast, may have come back to bite us again.
Next I'll revert to an earlier build.
A little while later:
Downgraded as far as 43800 skipping some of the intermediate builds, but no change. ICMP doesn't work.
Upgraded back to 43904 with reset and then restored saved settings. All to no avail. The test comes out 18/20 where it used to be 20/20 and it's due to ICMP not working (Not Tested as per the test result in grey).
A number of years ago when the IPv6 was being added into DDWRT I remember a firewall rule needed to be added to the IPv6 firewall to open up the ICMP port so you could at least get that 19/20, I always still needed to get a host name assigned from the ISP and with Spectrum its hard to explain that. I am in the process of trying to find the old threads showing that as I wish to try that again just for shits and giggles, my IPv6 works for me at 17/20 for years. _________________ Router/Version: Netgear R7800
File/Kernel: DD-WRT v3.0-r50671 std (10/26/22), Linux 4.9.330 #1313 SMP Wed Oct 26 05:13:03 +07 2022 armv7l
Joined: 05 Oct 2008 Posts: 666 Location: Helsinki, Finland / nr. Alkmaar, Netherlands
Posted: Fri Jul 24, 2020 2:39 Post subject:
pandemonium420 wrote:
ArjenR49 wrote:
R7800 now on build 43904.
The IPv6 test at https://ipv6-test.com/
finds a problem with ICMP.
I tried to enable and disable the Multicast filter and rebooting the router, but to no avail.
Whatever caused the recent flipping of Filter Multicast, may have come back to bite us again.
Next I'll revert to an earlier build.
A little while later:
Downgraded as far as 43800 skipping some of the intermediate builds, but no change. ICMP doesn't work.
Upgraded back to 43904 with reset and then restored saved settings. All to no avail. The test comes out 18/20 where it used to be 20/20 and it's due to ICMP not working (Not Tested as per the test result in grey).
A number of years ago when the IPv6 was being added into DDWRT I remember a firewall rule needed to be added to the IPv6 firewall to open up the ICMP port so you could at least get that 19/20, I always still needed to get a host name assigned from the ISP and with Spectrum its hard to explain that. I am in the process of trying to find the old threads showing that as I wish to try that again just for shits and giggles, my IPv6 works for me at 17/20 for years.
Some write that the test site mentioned above is unreliable, but after a number of hours ipv6 has broken and test result is only 4/20. This was typical for the situation where Filter Multicast was enabled. Ipv6 works after rebooting, but only for a while until the lack of ICMP response kills it.
This time, however, the filter multicast setting is disabled and the reason the problem cane back may be in the firewall rules I have added a little while ago.
I shall have to test without those rules and see what happens. Easy enough but can't do it just now.
If pandemonium can find the rule to allow ICMP traffic, I could test that with the other firewall rules in effect.
There's a plan ...
Joined: 05 Oct 2008 Posts: 666 Location: Helsinki, Finland / nr. Alkmaar, Netherlands
Posted: Fri Jul 24, 2020 4:52 Post subject:
ArjenR49 wrote:
pandemonium420 wrote:
ArjenR49 wrote:
R7800 now on build 43904.
The IPv6 test at https://ipv6-test.com/
finds a problem with ICMP.
I tried to enable and disable the Multicast filter and rebooting the router, but to no avail.
Whatever caused the recent flipping of Filter Multicast, may have come back to bite us again.
Next I'll revert to an earlier build.
A little while later:
Downgraded as far as 43800 skipping some of the intermediate builds, but no change. ICMP doesn't work.
Upgraded back to 43904 with reset and then restored saved settings. All to no avail. The test comes out 18/20 where it used to be 20/20 and it's due to ICMP not working (Not Tested as per the test result in grey).
A number of years ago when the IPv6 was being added into DDWRT I remember a firewall rule needed to be added to the IPv6 firewall to open up the ICMP port so you could at least get that 19/20, I always still needed to get a host name assigned from the ISP and with Spectrum its hard to explain that. I am in the process of trying to find the old threads showing that as I wish to try that again just for shits and giggles, my IPv6 works for me at 17/20 for years.
Some write that the test site mentioned above is unreliable, but after a number of hours ipv6 has broken and test result is only 4/20. This was typical for the situation where Filter Multicast was enabled. Ipv6 works after rebooting, but only for a while until the lack of ICMP response kills it.
This time, however, the filter multicast setting is disabled and the reason the problem cane back may be in the firewall rules I have added a little while ago.
I shall have to test without those rules and see what happens. Easy enough but can't do it just now.
If pandemonium can find the rule to allow ICMP traffic, I could test that with the other firewall rules in effect.
There's a plan ...
Commenting out the firewall rules didn't make a difference at all; test score still 18/20 only.
There are a lot of the TP-Link TL-WR*4*N* routers that are probably lacking 100% proper identification. We could probably spend a lot of time tracking this down and fixing it. My TL-WR940Nv3 is identified as a TL-WR941N(D)v6... there is probably some identifier that separates the two as they are identical, except one is re-branded as another model.
I can tell from my config backups that it was correct for my WR940NDv6 until 20200122. It was correct 20200120. That would mean something in the 20200121 version caused the 940NDv6 to show up as WR940ND v4_v5. r42054 is the release number. Just hoping this might help to track down at least that one router. I also have the TL-WR940Nv3, and it has been TL-WR941N(D)v6 ever since I TFTP recovered it, which used the 941 firmware. As you mentioned, it seems mostly cosmetic, thus I never reported it. But since I know exactly when the WR940NDv6 changed to WR940ND v4_v5, I was hoping this might help.
Joined: 05 Oct 2008 Posts: 666 Location: Helsinki, Finland / nr. Alkmaar, Netherlands
Posted: Fri Jul 24, 2020 8:59 Post subject:
ArjenR49 wrote:
ArjenR49 wrote:
pandemonium420 wrote:
ArjenR49 wrote:
R7800 now on build 43904.
The IPv6 test at https://ipv6-test.com/
finds a problem with ICMP.
I tried to enable and disable the Multicast filter and rebooting the router, but to no avail.
Whatever caused the recent flipping of Filter Multicast, may have come back to bite us again.
Next I'll revert to an earlier build.
A little while later:
Downgraded as far as 43800 skipping some of the intermediate builds, but no change. ICMP doesn't work.
Upgraded back to 43904 with reset and then restored saved settings. All to no avail. The test comes out 18/20 where it used to be 20/20 and it's due to ICMP not working (Not Tested as per the test result in grey).
A number of years ago when the IPv6 was being added into DDWRT I remember a firewall rule needed to be added to the IPv6 firewall to open up the ICMP port so you could at least get that 19/20, I always still needed to get a host name assigned from the ISP and with Spectrum its hard to explain that. I am in the process of trying to find the old threads showing that as I wish to try that again just for shits and giggles, my IPv6 works for me at 17/20 for years.
Some write that the test site mentioned above is unreliable, but after a number of hours ipv6 has broken and test result is only 4/20. This was typical for the situation where Filter Multicast was enabled. Ipv6 works after rebooting, but only for a while until the lack of ICMP response kills it.
This time, however, the filter multicast setting is disabled and the reason the problem cane back may be in the firewall rules I have added a little while ago.
I shall have to test without those rules and see what happens. Easy enough but can't do it just now.
If pandemonium can find the rule to allow ICMP traffic, I could test that with the other firewall rules in effect.
There's a plan ...
Commenting out the firewall rules didn't make a difference at all; test score still 18/20 only.
My observation that IPv6 breaks after some hours was made on my Xiaomi smartphone, assuming that as a relatively new device it does IPv6, when given the chance.
However ... at the same time when that smartphone gets 4/20 from ipv6-test.com, my laptop still gets 18/20, and full IPv6 connectivity according to the other test sites.
