What's new

Kamoj Kamoj information add-on V4 for Netgear R7800 X4S and R9000 X10 (Temperatures a.o.)

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Your internet is down for about a minute only. (That happens with many ISP subscriptions).

There are a lot of people having big problems with your modem type and Virgins services.
I would start to check your "Virgin Media Super Hub 3.0" modem, how does it behave when this happens?
Just google: Virgin Media Super Hub 3.0 disconnect

I really want to help you, but maybe this is not an add-on problem.
So to not clutter this thread - and for you to reach others to help you,
I suggest you stop using the add-on, and if you still have problems,
start a new thread/topic that draws attention from non-add-on users.

I don't see any indication of error in your R9000 router itself or the add-on.
I think you should check up your modem, your ISP and your OpenVPN-provider.
Also you can check the OpenVPN-client log and see what happens around that time.

I'll send you a private message with questions and suggestions!
Sad news.. last night the internet decided to drop off again :(
log attached.
Code:
=== IMPORTANT ============================
[Internet disconnected] Thursday, February 21, 2019 01:45:59
[Internet connected] IP address: 192.168.100.20, Thursday, February 21, 2019 01:47:32
[Internet connected] IP address: 192.168.100.20, Thursday, February 21, 2019 01:48:02
==================================
[Internet connected] IP address: 8x.1X.5x.7, Thursday, February 21, 2019 01:48:33
[DHCP IP: 192.168.1.5][Device Name: WISERHEAT028A80] to MAC address XX:XX:XX:XX:XX:80, Thursday, February 21, 2019 01:48:37
 
Your internet is down for about a minute only. (That happens with many ISP subscriptions).

There are a lot of people having big problems with your modem type and Virgins services.
I would start to check your "Virgin Media Super Hub 3.0" modem, how does it behave when this happens?
Just google: Virgin Media Super Hub 3.0 disconnect

I really want to help you, but maybe this is not an add-on problem.
So to not clutter this thread - and for you to reach others to help you,
I suggest you stop using the add-on, and if you still have problems,
start a new thread/topic that draws attention from non-add-on users.

I don't see any indication of error in your R9000 router itself or the add-on.
I think you should check up your modem, your ISP and your OpenVPN-provider.
Also you can check the OpenVPN-client log and see what happens around that time.

I'll send you a private message with questions and suggestions!
Thanks
I won't clutter this thread, but router didn't reconnect, it will probably reconnect without the add-on
Just wanted to add, i never said this was an add-on issue, rather a setting or something on my end is not playing nice with it.
 
Last edited:
Hi Kamoj,

Well, seems that I have a problem too. First day trying your awaited addon.

VPN works fine for about 10-15 minutes, then drops. Internet working, only R7800 no other router to access internet. This is my log (in bold maybe that's the fault..?). Any suggestions what to do?


root@R7800:/$ cat /var/log/openvpn-client.log

Thu Jan 1 00:00:28 UTC 1970 Voxel: OpenVPNclient stop run: ip route del:

192.168.2.0/24 dev br0 proto kernel scope link src 192.168.2.1

Mon Feb 25 14:42:12 2019 OpenVPN 2.4.6 arm-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]

Mon Feb 25 14:42:12 2019 library versions: OpenSSL 1.0.2q 20 Nov 2018, LZO 2.10

Mon Feb 25 14:42:12 2019 neither stdin nor stderr are a tty device and you have neither a controlling tty nor systemd - can't ask for 'Enter Auth Username:'. If you used --daemon, you need to use --askpass to make passphrase-protected keys work, and you can not use --auth-nocache.

Mon Feb 25 14:42:12 2019 Exiting due to fatal error

Mon Feb 25 14:42:13 2019 OpenVPN 2.4.6 arm-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]

Mon Feb 25 14:42:13 2019 library versions: OpenSSL 1.0.2q 20 Nov 2018, LZO 2.10

Mon Feb 25 14:42:13 2019 neither stdin nor stderr are a tty device and you have neither a controlling tty nor systemd - can't ask for 'Enter Auth Username:'. If you used --daemon, you need to use --askpass to make passphrase-protected keys work, and you can not use --auth-nocache.

Mon Feb 25 14:42:13 2019 Exiting due to fatal error

Error: OpenVPN client start failed.

Error: OpenVPN client start failed.

Mon Feb 25 14:45:06 2019 OpenVPN 2.4.6 arm-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]

Mon Feb 25 14:45:06 2019 library versions: OpenSSL 1.0.2q 20 Nov 2018, LZO 2.10

Mon Feb 25 14:45:21 2019 WARNING: --ping should normally be used with --ping-restart or --ping-exit

Mon Feb 25 14:45:21 2019 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

Mon Feb 25 14:45:21 2019 NOTE: --fast-io is disabled since we are not using UDP

Mon Feb 25 14:45:21 2019 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication

Mon Feb 25 14:45:21 2019 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication

Mon Feb 25 14:45:21 2019 nice -20 succeeded

Mon Feb 25 14:45:21 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]185.236.42.28:443

Mon Feb 25 14:45:21 2019 Socket Buffers: R=[87380->1048576] S=[16384->1048576]

Mon Feb 25 14:45:21 2019 Attempting to establish TCP connection with [AF_INET]185.236.42.28:443 [nonblock]

Mon Feb 25 14:45:22 2019 TCP connection established with [AF_INET]xxx.xxx.xx.xx:443

Mon Feb 25 14:45:22 2019 TCP_CLIENT link local: (not bound)

Mon Feb 25 14:45:22 2019 TCP_CLIENT link remote: [AF_INET]xxx.xxx.xx.xx:443

Mon Feb 25 14:45:22 2019 TLS: Initial packet from [AF_INET]xxx.xxx.xx.xx:443, sid=c1513521 d8ae602f

Mon Feb 25 14:45:22 2019 VERIFY OK: depth=2, C=PA, O=NordVPN, CN=NordVPN Root CA

Mon Feb 25 14:45:22 2019 VERIFY OK: depth=1, C=PA, O=NordVPN, CN=NordVPN CA3

Mon Feb 25 14:45:22 2019 VERIFY KU OK

Mon Feb 25 14:45:22 2019 Validating certificate extended key usage

Mon Feb 25 14:45:22 2019 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication

Mon Feb 25 14:45:22 2019 VERIFY EKU OK

Mon Feb 25 14:45:22 2019 VERIFY OK: depth=0, CN=se234.nordvpn.com

Mon Feb 25 14:45:22 2019 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA

Mon Feb 25 14:45:22 2019 [se234.nordvpn.com] Peer Connection Initiated with [AF_INET]185.236.42.28:443

Mon Feb 25 14:45:23 2019 SENT CONTROL [se234.nordvpn.com]: 'PUSH_REQUEST' (status=1)

Mon Feb 25 14:45:23 2019 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 103.86.96.100,dhcp-option DNS 103.86.99.100,sndbuf 524288,rcvbuf 524288,explicit-exit-notify,comp-lzo no,route-gateway 10.7.3.1,topology subnet,ping 60,ping-restart 180,ifconfig 10.7.3.3 255.255.255.0,peer-id 0,cipher AES-256-GCM'

Mon Feb 25 14:45:23 2019 OPTIONS IMPORT: timers and/or timeouts modified

Mon Feb 25 14:45:23 2019 OPTIONS IMPORT: --explicit-exit-notify can only be used with --proto udp

Mon Feb 25 14:45:23 2019 OPTIONS IMPORT: compression parms modified

Mon Feb 25 14:45:23 2019 OPTIONS IMPORT: --sndbuf/--rcvbuf options modified

Mon Feb 25 14:45:23 2019 Socket Buffers: R=[1048576->1048576] S=[1048576->1048576]

Mon Feb 25 14:45:23 2019 OPTIONS IMPORT: --ifconfig/up options modified

Mon Feb 25 14:45:23 2019 OPTIONS IMPORT: route options modified

Mon Feb 25 14:45:23 2019 OPTIONS IMPORT: route-related options modified

Mon Feb 25 14:45:23 2019 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified

Mon Feb 25 14:45:23 2019 OPTIONS IMPORT: peer-id set

Mon Feb 25 14:45:23 2019 OPTIONS IMPORT: adjusting link_mtu to 1659

Mon Feb 25 14:45:23 2019 OPTIONS IMPORT: data channel crypto options modified

Mon Feb 25 14:45:23 2019 Data Channel: using negotiated cipher 'AES-256-GCM'

Mon Feb 25 14:45:23 2019 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key

Mon Feb 25 14:45:23 2019 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key

Mon Feb 25 14:45:23 2019 TUN/TAP device tun0 opened

Mon Feb 25 14:45:23 2019 TUN/TAP TX queue length set to 1000

Mon Feb 25 14:45:23 2019 do_ifconfig, tt->did_ifconfig_ipv6_setup=0

Mon Feb 25 14:45:23 2019 /sbin/ifconfig tun0 10.7.3.3 netmask 255.255.255.0 mtu 1500 broadcast 10.7.3.255

Mon Feb 25 14:45:23 2019 /etc/openvpn/ovpnclient-up.sh tun0 1500 1587 10.7.3.3 255.255.255.0 init

Mon Feb 25 14:45:23 2019 /sbin/route add -net 185.236.42.28 netmask 255.255.255.255 gw 78.68.47.1

Mon Feb 25 14:45:23 2019 /sbin/route add -net 0.0.0.0 netmask 128.0.0.0 gw 10.7.3.1

Mon Feb 25 14:45:23 2019 /sbin/route add -net 128.0.0.0 netmask 128.0.0.0 gw 10.7.3.1

Mon Feb 25 14:45:23 2019 Initialization Sequence Completed

Mon Feb 25 15:45:21 2019 neither stdin nor stderr are a tty device and you have neither a controlling tty nor systemd - can't ask for 'Enter Auth Username:'. If you used --daemon, you need to use --askpass to make passphrase-protected keys work, and you can not use --auth-nocache.

Mon Feb 25 15:45:21 2019 Exiting due to fatal error

Mon Feb 25 15:45:21 2019 /sbin/route del -net 185.236.42.28 netmask 255.255.255.255

Mon Feb 25 15:45:21 2019 /sbin/route del -net 0.0.0.0 netmask 128.0.0.0

Mon Feb 25 15:45:21 2019 /sbin/route del -net 128.0.0.0 netmask 128.0.0.0

Mon Feb 25 15:45:21 2019 Closing TUN/TAP interface

Mon Feb 25 15:45:21 2019 /sbin/ifconfig tun0 0.0.0.0

Mon Feb 25 15:45:22 2019 /etc/openvpn/ovpnclient-down.sh tun0 1500 1587 10.7.3.3 255.255.255.0 init

root@R7800:/$
 
Basic Infomation
Router Information Router:R7800, HW_ID:29764958+0+128+512+4x4+4x4+cascade, SN:4H587550003C1. Region:WW (0x0002), Language:Eng,GR,FR,NL,SV,RU. WiFi Region:Europe
CPU Load Total (per core) 4.1% ( 3.2% 5.0% ) (System Load Average last: 1/5/15 minutes: 4.02 / 4.04 / 4.07)
Memory Usage (Used/Total) 217MB/472MB
Flash Usage (Used/Total) 110MB/128MB File system: squashfs. Block:mtdblock6 ("rootfs" 31.326MB). 7.535MB/49.836MB
NVRAM Usage (Used/Total) 38413/393216 bytes
Network Session (Active/Total) 1262/65536
CPU Governors and Frequencies 0: userspace 7% 1.725 GHz (100.0 %) 1: userspace 6% 1.725 GHz (100.0 %)
Temperatures CPU / WiFi0 / WiFi1 52 / 47 / 45 (Top=59 / 50 / 47) (Critical Max=80 / 90 / 90) °C 125 / 116 / 113 (Top=138 / 122 / 116) (Critical Max=176 / 194 / 194) °F
WiFi0 ath0 ESSID:"Nighthawk V" , CH:36+40+44(p)+48, Frequency:5.22 GHz Rate:1.7333 Gb/s, Tx-Power (100%):21 dBm (125 mW), RSSI:-66 -57 dBm
WiFi1 ath1 ESSID:"Nighthawk II" , CH:5(p)+9(s), Frequency:2.432 GHz Rate:800 Mb/s, Tx-Power (100%):19 dBm (79 mW), RSSI:-44 -76 dBm
OpenVPN Clients Available se234.ovpn
OpenVPN Client Name se234.nordvpn.com xxx.xxx.xx.xx:443
OpenVPN Client Status ERROR:
DNSCrypt v2 Servers DNSCrypt v2 is not running, but is enabled.
Congestion Control; Current ( Available ) yeah (yeah vegas reno cubic westwood highspeed illinois)
NTP synchronized OK: 2019-02-25 14:42:21: Boot sequence: 35+ seconds. Time then synchronized after 12 seconds. Synch indicators: (F)
DNS status OK, PING (www.cloudflare.com) www.cloudflare.com (198.41.215.162): time=3.9 ms
Internet connection status OK, PING 1.1.1.1 (one.one.one.one): time=3.9 ms
Port Status WAN:1000M/Full, LAN0:Link down, LAN1:1000M/Full, LAN2:100M/Full, LAN3:1000M/Full
WAN Speed (average value) Rx: 180.436 KB/s, Tx: 225.948 KB/s
USB Device USB2: OVPN R7800, SanDisk Corporation Cruzer Mini (Cruzer Mini) USB2.0. File system:VFAT. Size:0.950 GB, Used:0% (0.002 GB), Free: 0.948 GB
System Version Information Linux R7800 3.4.103 #1 SMP Mon Jan 28 10:13:25 UTC 2019 armv7l IPQ8065 / WiFi-driver:3.4.103+10.4-4.0.1756.382-1 / NETGEAR (Voxel) V1.0.2.63SF
System Uptime 0 days 1 hours 44 min 1 seconds (Mon Feb 25 16:25:24 GMT 2019 +0100)
Debug Log Capture
Start Debug Log Capture when boot up


Enable LAN/WAN Packet Capture

Store location



Enable Telnet

WAN Port mirror to LAN port1

Allow external IPv6 hosts ping internal IPv6 hosts

Enable 11k
 
The add-on should not affect the OpenVPN-Client.

What I can think of is that you still have an USB-memory with the OpenVPN-Client installation inserted in the router.
This is known to cause problems.
So be sure to remove the memory after installing the OpenVPN-client/configuration.

Run this command to see how many vpn processes there are:
Code:
ps w | grep -i vpn

You can of course uninstall the add-on and see if that solves the problem.

Also you can update the routers firmware to Voxel's .64SF that has a new OpenVPN version!

Hi Kamoj,

Well, seems that I have a problem too. First day trying your awaited addon.

VPN works fine for about 10-15 minutes, then drops. Internet working, only R7800 no other router to access internet. This is my log (in bold maybe that's the fault..?). Any suggestions what to do?


root@R7800:/$ cat /var/log/openvpn-client.log

Thu Jan 1 00:00:28 UTC 1970 Voxel: OpenVPNclient stop run: ip route del:

192.168.2.0/24 dev br0 proto kernel scope link src 192.168.2.1

Mon Feb 25 14:42:12 2019 OpenVPN 2.4.6 arm-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]

Mon Feb 25 14:42:12 2019 library versions: OpenSSL 1.0.2q 20 Nov 2018, LZO 2.10

Mon Feb 25 14:42:12 2019 neither stdin nor stderr are a tty device and you have neither a controlling tty nor systemd - can't ask for 'Enter Auth Username:'. If you used --daemon, you need to use --askpass to make passphrase-protected keys work, and you can not use --auth-nocache.

Mon Feb 25 14:42:12 2019 Exiting due to fatal error
 
Thanks! I'll remove my USB and update the firmware. When updating, does your addon stays in memory?

Running your command (before removing my USB-stick) returns this:

root@R7800:/$ ps w | grep -i vpn

693 root 316 S grep -i vpn

3395 root 1984 S < /usr/sbin/openvpn --fast-io --nice -20 --auth-nocache --sndbuf 786432 --rcvbuf 786432 --tun-mtu 1500 --mss
 
The add-on has to be installed again, and also the OpenVPN-Client.

Your issued command showed normal status.

Thanks! I'll remove my USB and update the firmware. When updating, does your addon stays in memory?

Running your command (before removing my USB-stick) returns this:

root@R7800:/$ ps w | grep -i vpn

693 root 316 S grep -i vpn

3395 root 1984 S < /usr/sbin/openvpn --fast-io --nice -20 --auth-nocache --sndbuf 786432 --rcvbuf 786432 --tun-mtu 1500 --mss
 
I have more details:

- without your plugin there are no warning messages
- they appear every 10 seconds
- they also appear in groups when refreshing your debug page
- warning are not log for initial minidlna scan which is taking around 50% of CPU load
- top is not showing any peaks of CPU util neither for those every 10 seconds nor while refreshing debug page but...
- debug page is showing higher current CPU load then with previous versions

Since I've upgraded in almost the same time firmware to 64SF and your plugin to v4 it's hard to tell but my gut feeling is warning messages are related to some upgraded firmware component causing high CPU util by your scripts. Maybe @Voxel is going to have some idea?
Anyway I had no such warnings prior to 64SF/v4 and although I understand warning itself is harmless it still might point out to some library issue causing high CPU load.

Yes, I have them too.
This error also exist without add-ons.
I've seen it in since I started using my R7800.
Sometimes there are more of these logs, sometimes less.
Are you getting more of them when running OpenVPN with high load?

I googled it long time ago, and as I remember the error is due o a bug in the kernel, corrected in kernel 4.x...
 
Well, VPN-client stopped again. Will try to do a factory reset when I have time, but first uninstall and install you add-on again.

"
root@R7800:/$
root@R7800:/$ /etc/init.d/openvpn-client start
PING www.google.com (216.58.211.4): 56 data bytes

--- www.google.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 3.9/3.9/3.9 ms
Enter Auth Username:xxxxx@xxx.xx

Enter Auth Password:
Please wait...
Error: OpenVPN client start failed.
/etc/rc.common: kill: 90: (28164) - No such process
root@R7800:/$
 
Thank you for reporting!

The add-on read the temperature sensors every 10 second to capture max temp even when debug page is not refreshed,
but that shouldn't cause any "kernel: [Warning] skb_warn_bad_offload!!!"... Hmm...
(In the first add-on I used another way of reading the temperatures, but when I made the code work for R9000 as well,
I changed the method of getting temperatures.)

I'm very grateful for your investigation, and will look further into it when I get the time!

I have more details:

- without your plugin there are no warning messages
- they appear every 10 seconds
- they also appear in groups when refreshing your debug page
- warning are not log for initial minidlna scan which is taking around 50% of CPU load
- top is not showing any peaks of CPU util neither for those every 10 seconds nor while refreshing debug page but...
- debug page is showing higher current CPU load then with previous versions

Since I've upgraded in almost the same time firmware to 64SF and your plugin to v4 it's hard to tell but my gut feeling is warning messages are related to some upgraded firmware component causing high CPU util by your scripts. Maybe @Voxel is going to have some idea?
Anyway I had no such warnings prior to 64SF/v4 and although I understand warning itself is harmless it still might point out to some library issue causing high CPU load.
Thank
 
Thank you for reporting.
I can not see how the add-on affects this, but to be sure
I suggest you run your VPN-client for a few days without add-on.

If it still fails, start a new thread about problems with the OpenVPN Client.

Well, VPN-client stopped again. Will try to do a factory reset when I have time, but first uninstall and install you add-on again.

"
root@R7800:/$
root@R7800:/$ /etc/init.d/openvpn-client start
PING www.google.com (216.58.211.4): 56 data bytes

--- www.google.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 3.9/3.9/3.9 ms
Enter Auth Username:xxxxx@xxx.xx

Enter Auth Password:
Please wait...
Error: OpenVPN client start failed.
/etc/rc.common: kill: 90: (28164) - No such process
root@R7800:/$
 
you acn also let me know what to change to revert to former temperature reading method, assuming that's just a few lines

Thank you for reporting!

The add-on read the temperature sensors every 10 second to capture max temp even when debug page is not refreshed,
but that shouldn't cause any "kernel: [Warning] skb_warn_bad_offload!!!"... Hmm...
(In the first add-on I used another way of reading the temperatures, but when I made the code work for R9000 as well,
I changed the method of getting temperatures.)

I'm very grateful for your investigation, and will look further into it when I get the time!


Thank
 
I have investigated the cause of the dmesg logs:

It was not caused by reading temperatures, but the by-pass-openvpn-code.
I change this code not to give any warnings.

They were all caused by my add-on using Netgear stock functions:
(None of my code caused this!)
  • nvram show (config show)
    [Warning] skb_warn_bad_offload!!!
  • sysctl -a
    Frequency Set to 800000000
    Frequency Supported - 110Mhz 600Mhz 800Mhz
    Current Inst Per Ms 0
  • /sbin/show_usb_sata_info
    [Warning] skb_warn_bad_offload!!!
I have made another code for the "systctl -a", so those errors are gone now.
I have changed the code so the [Warning] skb_warn_bad_offload!!! is not received cyclic any longer,
but there will be 3 of them logged when the debug page is refreshed.
Also Netgear's stock debug page gives these warnings!
So it's under control.

I have not found that this warning is of any importance.
I have commented your post with red color below.

:)Thank you again for being alert, supporting the community and reporting this issue!:)

PS
While investigating this I added timestamps to the dmesg log. Coming in next add-on version.

I have more details:

- without your plugin there are no warning messages
YES there are! If you load Netgear's stock debug page, the Warnings come!
- they appear every 10 seconds
Yes, that is fixed
- they also appear in groups when refreshing your debug page
Yes, that is fixed
- warning are not log for initial minidlna scan which is taking around 50% of CPU load
- top is not showing any peaks of CPU util neither for those every 10 seconds nor while refreshing debug page but...
- debug page is showing higher current CPU load then with previous versions
Must be because of new Voxel/Netgear code? The Add-on should not use any more CPU.

Since I've upgraded in almost the same time firmware to 64SF and your plugin to v4 it's hard to tell but my gut feeling is warning messages are related to some upgraded firmware component causing high CPU util by your scripts. Maybe @Voxel is going to have some idea?
Anyway I had no such warnings prior to 64SF/v4 and although I understand warning itself is harmless it still might point out to some library issue causing high CPU load.
I have not been able to see any increased CPU load.
What do you mean with high CPU load?
How do you measure the load?
 
Last edited:
Regarding higher CPU load: that was my hypothesis based on what you wrote about openvpn generating that error and higher load shown by debug page. However as I wrote top is not showing any CPU peaks.
Thank you anyway for quickly identifying the issue and sorting it out!
Anyway I am rarely using dmesg relying instead on syslog which most of the time is with proper timestamps. So unless you configure syslogd to send messages to external host logread should show them with timestamps.

I have investigated the cause of the dmesg logs:

It was not caused by reading temperatures, but the by-pass-openvpn-code.
I change this code not to give any warnings.

They were all caused by my add-on using Netgear stock functions:
(None of my code caused this!)
  • nvram show (config show)
    [Warning] skb_warn_bad_offload!!!
  • sysctl -a
    Frequency Set to 800000000
    Frequency Supported - 110Mhz 600Mhz 800Mhz
    Current Inst Per Ms 0
  • /sbin/show_usb_sata_info
    [Warning] skb_warn_bad_offload!!!
I have made another code for the "systctl -a", so those errors are gone now.
I have changed the code so the [Warning] skb_warn_bad_offload!!! is not received cyclic any longer,
but there will 3 of them logged when the debug page is refreshed.
Also Netgear's stock debug page gives these warnings!
So it's under control.

I have not found that this warning is of any importance.
I have commented your post with red color below.

:)Thank you again for being alert, supporting the community and reporting this issue!:)

PS
While investigating this I added timestamps to the dmesg log. Coming in next add-on version.
 
Hello Kamoj (and others)!

After hours of testing with and without you add-on I discovered that the .ovpn file caused the problem with VPN-client being turned off after about 15 minutes.

I remember you told me long time ago to use a Linux text editor (not Notepad e.g.) to edit the .ovpn file. Using both Mac and Windows, can you recommend any Linux text editor for these platforms?
 
Voxel has added the tool you need in 64SF: dos2unix

Login to router and run:
Code:
dos2unix -u full_path_and_name_to.ovpn

PS
I am using UltraEdit myself - most of the time. It has built-in conversion etc.
But it might be a little overkill for you.

Hello Kamoj (and others)!

After hours of testing with and without you add-on I discovered that the .ovpn file caused the problem with VPN-client being turned off after about 15 minutes.

I remember you told me long time ago to use a Linux text editor (not Notepad e.g.) to edit the .ovpn file. Using both Mac and Windows, can you recommend any Linux text editor for these platforms?
 
I would recommend notepad++. Anyway next iteration of windows 10 should contain notepad with Unix line ending support.

Voxel has added the tool you need in 64SF: dos2unix

Login to router and run:
Code:
dos2unix -u full_path_and_name_to.ovpn

PS
I am using UltraEdit myself - most of the time. It has built-in conversion etc.
But it might be a little overkill for you.
 
Hello,

Have installed the kamoj add-on on my r9000. Everything looks great, however, the field where we can set and change the temperature values and fan speed gone.
Is it normal or do I have to change/enable any additional function now ?

Cheers,
A
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top