Custom firmware build for R7800 v. 1.0.2.49SF

[microchip]

This is the ICMPv6 section of my Linux firewall rules. Might help someone. With these, I get a solid 20/20 score on the test site

-A INPUT -p icmpv6 --icmpv6-type echo-request -m recent --set
-A INPUT -p icmpv6 --icmpv6-type echo-request -m recent --update --seconds 10 --hitcount 5 -j DROP
-A INPUT -p icmpv6 --icmpv6-type echo-request -j ACCEPT
-A INPUT -p icmpv6 --icmpv6-type echo-reply -j ACCEPT
-A INPUT -p icmpv6 --icmpv6-type router-advertisement -j ACCEPT
-A INPUT -p icmpv6 --icmpv6-type router-solicitation -j ACCEPT
-A INPUT -p icmpv6 --icmpv6-type neighbour-advertisement -j ACCEPT
-A INPUT -p icmpv6 --icmpv6-type neighbour-solicitation -j ACCEPT
-A INPUT -p icmpv6 --icmpv6-type destination-unreachable -j ACCEPT
-A INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT
-A INPUT -p icmpv6 --icmpv6-type time-exceeded -j ACCEPT
-A INPUT -p icmpv6 --icmpv6-type parameter-problem -j ACCEPT

PS: my Android phone also gets a solid 20/20 on the site so it's not just my Linux computers

 

[Gouzmalix]

Even though Traffic Meter monthly limit is limited to 6 digits, the actual value can be higher, as seen in the image below.

Spoiler

 

[avtella]

Seems like the "Secured" setting in IPv6 is faulty, upon one restart it finally stopped filtering when set to "Open". However after using the router as an AP for another R7800 on LEDE and then going back to router mode it once again started filtering ICMPv6 despite the "Open" setting.

As for Windows side of things you may wanna try this:
netsh advfirewall firewall add rule name="ICMPv6 echo request" protocol=icmpv6:8,any dir=in action=allow - courtesy of http://www.dslreports.com/forum/r31364975-DSL-IPv6-ICMP-filtering-fix-how

However I found I needed to go to the newly added rule in Windows Firewall and under Protocols and Ports (of the rule) go to ICMP Settings "Customize" and select "All ICMP Types" or check mark the individual ones that allow the test to pass and get a 20/20, now you shouldn't get the ICMP Filtered warning in the IPV6 Test site assuming the R7800 decides to adhere to the "Open" option at the moment.

 

[RMerlin]

This is the ICMPv6 section of my Linux firewall rules. Might help someone. With these, I get a solid 20/20 score on the test site

-A INPUT -p icmpv6 --icmpv6-type echo-request -m recent --set
-A INPUT -p icmpv6 --icmpv6-type echo-request -m recent --update --seconds 10 --hitcount 5 -j DROP
-A INPUT -p icmpv6 --icmpv6-type echo-request -j ACCEPT
-A INPUT -p icmpv6 --icmpv6-type echo-reply -j ACCEPT
-A INPUT -p icmpv6 --icmpv6-type router-advertisement -j ACCEPT
-A INPUT -p icmpv6 --icmpv6-type router-solicitation -j ACCEPT
-A INPUT -p icmpv6 --icmpv6-type neighbour-advertisement -j ACCEPT
-A INPUT -p icmpv6 --icmpv6-type neighbour-solicitation -j ACCEPT
-A INPUT -p icmpv6 --icmpv6-type destination-unreachable -j ACCEPT
-A INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT
-A INPUT -p icmpv6 --icmpv6-type time-exceeded -j ACCEPT
-A INPUT -p icmpv6 --icmpv6-type parameter-problem -j ACCEPT

PS: my Android phone also gets a solid 20/20 on the site so it's not just my Linux computers

Haven't tested my 6in4 tunnel lately, but here's what Asus lets through:

https://github.com/RMerl/asuswrt-merlin.ng/blob/master/release/src/router/rc/firewall.c#L76

 

[Razor512]

Has anyone experienced a strange issue where they lose all WAN connectivity, and the router suddenly thinks you moved from the US to Europe along with not knowing any of the WiFi settings?

I just now had this issue which went away when I simply power cycled the router.

Sadly none of the options within the debug page would respond, thus I could not capture any logs.

 

[bouwew]

@Voxel I recently found your github and noticed the pull request by dissent1. Seems quite interesting. did you ever try try this?

 

[Gouzmalix]

@Voxel Traffic Meter data will completely erase after reboot using your firmware. This behavior is not seen with factory firmware. Could it be that the storage location of the data is different, or isn't mounted properly?

EDIT: Selecting time change (DST) in Schedule, then deselecting it again restores the data. Also, for what it's worth, there is a couple of observed minutes that the connection for all clients connected will not be able to load anything. As far as I can tell, this is caused by the options located under "Traffic control"; it only shows itself when the conditions are triggered.

 

[Voxel]

@Voxel Traffic Meter data will completely erase after reboot using your firmware. This behavior is not seen with factory firmware. Could it be that the storage location of the data is different, or isn't mounted properly?

EDIT: Selecting time change (DST) in Schedule, then deselecting it again restores the data. Also, for what it's worth, there is a couple of observed minutes that the connection for all clients connected will not be able to load anything. As far as I can tell, this is caused by the options located under "Traffic control"; it only shows itself when the conditions are triggered.

Well, thanks for your report. It is strange for me because traffic meter is enclosed package (just two binaries and one script in NG's GPL) and I use it "as-is" w/o my changes. And moreover, script which starts traffic meter begins with command which copies all to /tmp i.e. to RAM and thus this should be really lost after reboot:

. . .
start)
    echo -n "traffic_meter start : "
    cp -arf /usr/traffic_meter/ /tmp/
. . .

Well, I'll check more.

Voxel.

 

[Voxel]

@Voxel I recently found your github and noticed the pull request by dissent1. Seems quite interesting. did you ever try try this?

Yes I played with this in July and second attempt at the end of August. While results were rather negative. Reason: too outdated sources of Linux and their drivers used in the stock. This Linux is a part of QCA SDK

https://source.codeaurora.org/quic/qsdk/oss/kernel/linux-msm/tree/?h=banana

but too old version.

I've got degradation of speed for OpenSSL.

I cannot significantly change Linux kernel because of pre-built drivers.

Anyway dissent pushed me to try the similar approach with /dev/crypto for R9000 and here I succeed.

(But there are some ideas and plans for R7800 too Not this pull, but the same direction).

Voxel.

 

[RogerSC]

I'm using the latest stock firmware *gasp* at the moment, and my traffic meter is at all 0's as usual. If I deselect auto Daylight Saving Time (DST), then I get some numbers. But I want DST since I live in a time zone with DST *smile*. I could do DST manually, and may do that if this turns out to be a long term problem, but I'd like to see Netgear fix this. Of course, I can't report it, since I've had the R7800 too long to have that kind of support. So it goes.

 

[bouwew]

@Voxel I wanted to make you aware of this topic: https://forum.lede-project.org/t/possible-cause-of-r7800-latency-issues/12872
Maybe something will come up that you could use in the future...

 

[kamoj]

Added some info about the OpenVPN Client into the debug-menu.
It was not so difficult.
Too bad no one can help with the GUI things.

It was easy to show in the GUI which openvpn client that is selected/used. But to show status for it, especially dynamically updated, is difficult for me.

I don't know how to make a GUI, I don't even now how to code HTML/Java,
so I hope someone else can join this forum and help to at least make a template!

 

[avtella]

@Voxel I wanted to make you aware of this topic: https://forum.lede-project.org/t/possible-cause-of-r7800-latency-issues/12872
Maybe something will come up that you could use in the future...

If I’m not mistaken, it’s not an issue in stock or stock based firmware (using 3.X kernel) like Voxel’s. I personally haven’t seen it in stock either, I have only seen it in LEDE/OpenWRT.

 

[Voxel]

If I’m not mistaken, it’s not an issue in stock or stock based firmware (using 3.X kernel) like Voxel’s. I personally haven’t seen it in stock either, I have only seen it in LEDE/OpenWRT.

Yeah. I failed to reproduce such problem.

Voxel.

 

[Gouzmalix]

If I’m not mistaken, it’s not an issue in stock or stock based firmware (using 3.X kernel) like Voxel’s. I personally haven’t seen it in stock either, I have only seen it in LEDE/OpenWRT.

Yeah, it seems to be an issue with the linux kernels 4+. Stock firmware (even with Voxel's) has no latency issues whatsoever, and it's no coincidence that stock firmware is using linux 3.4.103.

Some theories as to why have been proposed: users of the OpenWRT community say it has something to do with new kernel code interfering with the QCA (Qualcomm Atheros) drivers, while Kong from DD-WRT thinks it's broken PCIe code... Certainly not the first time issues came up for the R7800 on newer kernels; e.g. fq_codel had (still does to this day?) observable, worse performance when compared to cake as the queuing discipline.

 

[fantom]

Yeah. I failed to reproduce such problem.
Voxel.

This problem definitely does not exist in the stock firmware. May I ask you to check what frequency scaling governor is used in the stock firmware? I would need to reflash the router to check, but my family already hates me for messing with the Internet.

 

[kamoj]

It's ondemand for both cpu cores.
(There is code to to set it to userspace in a "turbo-mode", but that is not used afaik.
I'm doing some experiments with it, but so far no exciting results...)

This problem definitely does not exist in the stock firmware. May I ask you to check what frequency scaling governor is used in the stock firmware? I would need to reflash the router to check, but my family already hates me for messing with the Internet.

 

[bouwew]

Yeah. I failed to reproduce such problem.

Voxel.

I know that stock-/Voxel-firmware does not have the latency-problem.

I wanted to draw your attention to the thread for the possible solutions that might surface, like the alternative kernel-settings that fantom-x is experimenting with.
I would not mind to see possible improvements found in that thread to be ported into your firmware

 

[fantom]

It's ondemand for both cpu cores.

Thank you for checking. I also wander how the interrupts are assigned. Can you run cat /proc/interrupts?

 

[kamoj]

Thank you for checking. I also wander how the interrupts are assigned. Can you run cat /proc/interrupts?

Sorry, I am running an OpenVPN client at the moment:
Voxels 49SF: (Without OpenVPN client the IRQ 264 are bound to cpu1.)

root@R7800:/$ cat /proc/interrupts
            CPU0       CPU1
  17:          0          0       GIC  dg_timer
  18:   59102049   43456576       GIC  gp_timer
  20:          0          0       GIC  qcom_wdt_bark_handler
  30:          0          0       GIC  MSM_L1
  34:          0          0       GIC  MSM_L2
  48:          0          0       GIC  msmgpio
  51:        224          0       GIC  rpm_drv
  52:          0          0       GIC  mpm_drv
  53:          0          0       GIC  rpm_err
  54:          0          0       GIC  pm_drv
  67:          0          0       GIC  msm_pcie_msi
  68:       1698    3132615       GIC  wifi0
  89:          0          0       GIC  msm_pcie_msi
  90:    4654909          0       GIC  wifi1
 137:          0          0       GIC  sps
 142:          0          0       GIC  xhci-hcd:usb1
 184:    2275077          0       GIC  msm_serial_hsl1
 187:          1          0       GIC  spi_qsd
 189:          0          0       GIC  spi_qsd
 202:   13286682          0       GIC  msmdatamover
 210:          0          0       GIC  tsens_interrupt
 217:          0          0       GIC  msm_ebi_erp.0
 237:          0          0       GIC  xhci-hcd:usb3
 241:          0          0       GIC  ahci
 245:   92499127          0       GIC  nss
 246:    6427316          0       GIC  nss
 264:    8717273        127       GIC  nss
 265:          0          0       GIC  nss
 294:          0          0   msmgpio  wifi_onoff
 342:          0          0   msmgpio  reset
 353:          0          0   msmgpio  WPS
IPI0:          0          0  CPU start interrupts
IPI1:          0          0  Timer broadcast interrupts
IPI2:    4028328   34838621  Rescheduling interrupts
IPI3:          0          0  Function call interrupts
IPI4:       6335      12798  Single function call interrupts
IPI5:          0          0  CPU stop interrupts
IPI6:          0          0  CPU backtrace
 Err:          0