New Build - 11/03/2020 - r44715

Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Marvell MVEBU based Hardware (WRT1900AC etc.)
Author Message
blkt
DD-WRT Guru


Joined: 20 Jan 2019
Posts: 2040

PostPosted: Tue Nov 03, 2020 19:02    Post subject: New Build - 11/03/2020 - r44715 Reply with quote
[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.


Downloads: (DD-WRT website) HTTPS & FTP (try another if a link doesn't work)

CLI Flash: 'cd /tmp' then 'wget {file URL}' (or 'curl -k {file URL} -o {file}') with http (not https) or ftp. Then 'write {file} linux'.

Repository: Trac SVN changelog since last build r44700 (GitHub mirror)

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.20200908 & Tools: PBR, Kill Switch, Inbound Firewall, Naming of Peers, Status, Key, Guides. Thanks BS & egc!
• OpenVPN Version 2.5.0

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, tcpdump etc.
• For firewall NAT or WAN issues provide 'iptables -vnL', 'iptables -t nat -vnL', 'iptables -t mangle -vnL' 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.

Example Template:
Code:
[b]Router/Version: [/b]
[b]File/Kernel: [/b]
[b]Previous/Reset: [/b]
[b]Mode/Status: [/b]
[b]Issues/Errors: [/b]
Sponsor
Monza
DD-WRT User


Joined: 01 Jul 2018
Posts: 225

PostPosted: Wed Nov 04, 2020 13:10    Post subject: Reply with quote
Upgraded WRT1200AC v1's from r44700 to r44715 using Brave Version 1.10.97 (64-bit) running on Linux Mint 20 OS.

Successful update and reboot. No reset, nothing disabled prior to update, uptime aproximatly 15 hrs, wired/wireless connected, vpn up immediately (Expressvpn). I do not use NAS. SFE is always disabled. OpenVPN client/DNSMasq, QoS with PIE always enabled.

Kernel Version Linux 4.9.241 #2174 SMP Tue Nov 3 02:44:43 +03 2020 armv7l

No issues. I do not have any Apple devices.
Argenis
DD-WRT User


Joined: 18 Feb 2019
Posts: 89

PostPosted: Thu Nov 05, 2020 10:52    Post subject: Reply with quote
WRT3200ACM upgraded while wiping via GUI.

So far so good, all three wireless interfaces are available, temperatures and CPU usage is great.

Will update if there's any issues.

_________________
Router: Linksys WRT3200ACM
88W8964 802.11ac WLAN0 Mode AP VHT80 80MHz Mixed Mode Channel and Extension Auto
88W8964 802.11ac WLAN1 Mode AP 20 MHz Mixed Mode Channel and Extension Auto
SD8887 802.11ac disabled but visible on GUI and CLI
OpenVPN enabled, client mode
Port forwarding disabled
DHCP server mode, enabled
DNSCrypt and Validate DNS Replies
Wireless security is WPA2 Personal CCMP only
PIZZEDMEOFF
DD-WRT User


Joined: 12 Dec 2017
Posts: 238
Location: FL

PostPosted: Thu Nov 05, 2020 11:46    Post subject: Reply with quote
been running great on my setup, it is pretty basic though
_________________
Downloads:
ftp site: ftp://ftp.dd-wrt.com/betas/2020
SVN Timeline:
https://svn.dd-wrt.com/timeline
Commands:
Misc: sleep 10;stopservice nas;stopservice wlconf;startservice wlconf;startservice nas
samba: { sleep 30; stopservice samba3; startservice samba3; } &

WRT1900ACv1:

WIFI: 2.4ghz: NG-mixed, 20mhz channel width, channel follows AP, WPA2-CCMP-128.
WIFI: 5ghz: AC/N mixed, 40mhz channel width, channel 100+upper, WPA2-CCMP-128.
Misc Info: WPA2 Personal: "CCMP-128 (AES)" Static IP's VIA Mac+Host, SFE Enabled, No Rebind, Strict, no-resolv. NOTE: this is now just a wireless access point so to speak but all settings still apply to what ever wireless person connects.
oliver44
DD-WRT User


Joined: 01 Jun 2016
Posts: 107

PostPosted: Sun Nov 08, 2020 5:59    Post subject: Reply with quote
Router Model Linksys WRT1900ACS v2
Connection Type PPP0E-OK +ipv6 DHCP with Prefix Delegation-ok
Port Range Forwarding-ok
Dnsmasq,DNSCrypt-ok


The web interface is stable and ipv6 is no longer lost:!:
The only problem remains the wifi part which is unstable in the speedtest, during the speed test I left a ping on the router and it is clear that the response time increases

in the link below you have all the information with the tests, to view an image in the original format y click on the image, click right on the image and choose the image viewing option!

http://s.go.ro/lgpaxi7b

_________________
Internet provider https://en.wikipedia.org/wiki/RCS_%26_RDS RCS & RDS 1Gbps
Linksys WRT1900ACS v.2 - SuperWrt/OpenWrt
WDR3600 rev.1.5 - SuperWrt/OpenWrt
https://superwrt.download/
https://discord.gg/cEKuKbc
pbphoto
DD-WRT User


Joined: 29 Oct 2017
Posts: 124

PostPosted: Sun Nov 08, 2020 11:07    Post subject: Reply with quote
Oliver44 - do you have QOS enabled? If not, try enabling QOS on the WAN port (HTB, Cake) with your upload and download speeds set to ~90% of your ISP's throughput. Don't set priorities on anything else - leave the rest of the page alone. I found that just having basic QOS enabled like this helps stabilize ping times when running multiple simultaneous speedtests.
ho1Aetoo
DD-WRT User


Joined: 19 Feb 2019
Posts: 471

PostPosted: Sun Nov 08, 2020 11:30    Post subject: Reply with quote
the ping test is between the PC and the router and QoS on the WAN will not help

atheros (ath10k) routers have fq_codel and AQL (Airtime Queue Limits) in the WLAN drivers

this works quite well Wink
but it is also a bit dependent on the client and its driver

ping -i 0,2 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) Bytes Daten.
64 Bytes von 192.168.1.1: icmp_seq=1 ttl=64 Zeit=1.34 ms
64 Bytes von 192.168.1.1: icmp_seq=2 ttl=64 Zeit=1.53 ms
64 Bytes von 192.168.1.1: icmp_seq=3 ttl=64 Zeit=2.48 ms
64 Bytes von 192.168.1.1: icmp_seq=4 ttl=64 Zeit=1.15 ms
64 Bytes von 192.168.1.1: icmp_seq=5 ttl=64 Zeit=1.87 ms
64 Bytes von 192.168.1.1: icmp_seq=6 ttl=64 Zeit=7.65 ms
64 Bytes von 192.168.1.1: icmp_seq=7 ttl=64 Zeit=3.55 ms
64 Bytes von 192.168.1.1: icmp_seq=8 ttl=64 Zeit=2.00 ms
64 Bytes von 192.168.1.1: icmp_seq=9 ttl=64 Zeit=2.42 ms
64 Bytes von 192.168.1.1: icmp_seq=10 ttl=64 Zeit=3.08 ms
64 Bytes von 192.168.1.1: icmp_seq=11 ttl=64 Zeit=0.790 ms
64 Bytes von 192.168.1.1: icmp_seq=12 ttl=64 Zeit=0.951 ms
64 Bytes von 192.168.1.1: icmp_seq=13 ttl=64 Zeit=1.31 ms
64 Bytes von 192.168.1.1: icmp_seq=14 ttl=64 Zeit=1.87 ms
64 Bytes von 192.168.1.1: icmp_seq=15 ttl=64 Zeit=3.47 ms
64 Bytes von 192.168.1.1: icmp_seq=16 ttl=64 Zeit=3.57 ms
64 Bytes von 192.168.1.1: icmp_seq=17 ttl=64 Zeit=4.38 ms
64 Bytes von 192.168.1.1: icmp_seq=18 ttl=64 Zeit=3.23 ms
64 Bytes von 192.168.1.1: icmp_seq=19 ttl=64 Zeit=2.18 ms
64 Bytes von 192.168.1.1: icmp_seq=20 ttl=64 Zeit=3.68 ms
64 Bytes von 192.168.1.1: icmp_seq=21 ttl=64 Zeit=2.17 ms
64 Bytes von 192.168.1.1: icmp_seq=22 ttl=64 Zeit=1.88 ms
64 Bytes von 192.168.1.1: icmp_seq=23 ttl=64 Zeit=1.45 ms
64 Bytes von 192.168.1.1: icmp_seq=24 ttl=64 Zeit=1.33 ms
64 Bytes von 192.168.1.1: icmp_seq=25 ttl=64 Zeit=2.00 ms
64 Bytes von 192.168.1.1: icmp_seq=26 ttl=64 Zeit=4.12 ms
64 Bytes von 192.168.1.1: icmp_seq=27 ttl=64 Zeit=3.94 ms
64 Bytes von 192.168.1.1: icmp_seq=28 ttl=64 Zeit=1.02 ms
64 Bytes von 192.168.1.1: icmp_seq=29 ttl=64 Zeit=2.78 ms
64 Bytes von 192.168.1.1: icmp_seq=30 ttl=64 Zeit=5.82 ms
64 Bytes von 192.168.1.1: icmp_seq=31 ttl=64 Zeit=4.75 ms
64 Bytes von 192.168.1.1: icmp_seq=32 ttl=64 Zeit=3.47 ms
64 Bytes von 192.168.1.1: icmp_seq=33 ttl=64 Zeit=3.56 ms
64 Bytes von 192.168.1.1: icmp_seq=34 ttl=64 Zeit=6.10 ms
64 Bytes von 192.168.1.1: icmp_seq=35 ttl=64 Zeit=5.19 ms
64 Bytes von 192.168.1.1: icmp_seq=36 ttl=64 Zeit=4.81 ms
64 Bytes von 192.168.1.1: icmp_seq=37 ttl=64 Zeit=3.72 ms
64 Bytes von 192.168.1.1: icmp_seq=38 ttl=64 Zeit=2.63 ms
64 Bytes von 192.168.1.1: icmp_seq=39 ttl=64 Zeit=4.50 ms
64 Bytes von 192.168.1.1: icmp_seq=40 ttl=64 Zeit=4.56 ms
64 Bytes von 192.168.1.1: icmp_seq=41 ttl=64 Zeit=4.29 ms
64 Bytes von 192.168.1.1: icmp_seq=42 ttl=64 Zeit=3.56 ms
64 Bytes von 192.168.1.1: icmp_seq=43 ttl=64 Zeit=5.34 ms
64 Bytes von 192.168.1.1: icmp_seq=44 ttl=64 Zeit=5.33 ms
64 Bytes von 192.168.1.1: icmp_seq=45 ttl=64 Zeit=5.26 ms
64 Bytes von 192.168.1.1: icmp_seq=46 ttl=64 Zeit=3.53 ms
64 Bytes von 192.168.1.1: icmp_seq=47 ttl=64 Zeit=5.70 ms
64 Bytes von 192.168.1.1: icmp_seq=48 ttl=64 Zeit=11.2 ms
64 Bytes von 192.168.1.1: icmp_seq=49 ttl=64 Zeit=28.3 ms
64 Bytes von 192.168.1.1: icmp_seq=50 ttl=64 Zeit=3.25 ms
64 Bytes von 192.168.1.1: icmp_seq=51 ttl=64 Zeit=5.28 ms
64 Bytes von 192.168.1.1: icmp_seq=52 ttl=64 Zeit=4.57 ms
64 Bytes von 192.168.1.1: icmp_seq=53 ttl=64 Zeit=6.66 ms
64 Bytes von 192.168.1.1: icmp_seq=54 ttl=64 Zeit=5.03 ms
64 Bytes von 192.168.1.1: icmp_seq=55 ttl=64 Zeit=2.57 ms
64 Bytes von 192.168.1.1: icmp_seq=56 ttl=64 Zeit=3.47 ms
64 Bytes von 192.168.1.1: icmp_seq=57 ttl=64 Zeit=3.49 ms
64 Bytes von 192.168.1.1: icmp_seq=58 ttl=64 Zeit=4.98 ms
64 Bytes von 192.168.1.1: icmp_seq=59 ttl=64 Zeit=3.70 ms
64 Bytes von 192.168.1.1: icmp_seq=60 ttl=64 Zeit=5.91 ms
64 Bytes von 192.168.1.1: icmp_seq=61 ttl=64 Zeit=3.85 ms
64 Bytes von 192.168.1.1: icmp_seq=62 ttl=64 Zeit=4.36 ms
64 Bytes von 192.168.1.1: icmp_seq=63 ttl=64 Zeit=4.37 ms
64 Bytes von 192.168.1.1: icmp_seq=64 ttl=64 Zeit=6.61 ms
........
--- 192.168.1.1 ping statistics ---
143 Pakete übertragen, 143 empfangen, 0% Paketverlust, Zeit 28515ms
rtt min/avg/max/mdev = 0.790/4.479/28.313/3.007 ms

[SUM] 0.00-30.83 sec 2.71 GBytes 754 Mbits/sec receiver

for testing is recommended as in the example "ping -i 0,2"

2-3 seconds like in oliver44's test are very bad
oliver44
DD-WRT User


Joined: 01 Jun 2016
Posts: 107

PostPosted: Sun Nov 08, 2020 17:13    Post subject: Reply with quote
That ping becomes unstable only during the speedtest on the wifi side!
On the wire it behaves normally, i do not have active QOS!

@ho1Aetoo you should know that I found older versions with ddwrt where the ping during the speed test behaves normally on the wifi side....

_________________
Internet provider https://en.wikipedia.org/wiki/RCS_%26_RDS RCS & RDS 1Gbps
Linksys WRT1900ACS v.2 - SuperWrt/OpenWrt
WDR3600 rev.1.5 - SuperWrt/OpenWrt
https://superwrt.download/
https://discord.gg/cEKuKbc
RCShadows
DD-WRT User


Joined: 17 Aug 2008
Posts: 437

PostPosted: Tue Nov 10, 2020 20:46    Post subject: Reply with quote
Seems to be working well for my WRT3200ACM. I appreciate your effort as this router has been a PIA. As you can see I have been using DD-WRT for some time now with my membership length on the board.

Thank you again.

RCShadows
PavelVD
DD-WRT User


Joined: 26 Jul 2019
Posts: 67

PostPosted: Thu Nov 12, 2020 13:23    Post subject: Reply with quote
Router: Linksys WRT1900ACSv2
Firmware DD-WRT v3.0-r44715 std (11/03/20)
Kernel Linux 4.9.241 #2174 SMP Tue Nov 3 02:44:43 +03 2020 armv7l
Reset: No.
Mode:
QoS Enable: HTB, CAKE
Dnsmasq + SmartDNS
5 GHz: AP AC/N-Mixed, Wide NT40, Channel 149+Upper, Allow Channel Overlapping, Short Preamble, Short GI, Single User Beamforming.
2.4 GHz: AP NG-Mixed, Channel 5, Full 20 MHz, TurboQAM (QAM256) support, Short Preamble, Short GI.
Security: WPA2 Personal CCMP-128 (AES)
The "ap_max_inactivity 600" option improves the situation a little bit for iOS customers, but in general it's still bad. The customer falls off and can't connect for a long time.
NAS via USB:
/dev/sda - Block device, size 931.5GiB, Partition: 1-Ext4, 2-Ext4 , 3-swap.
ProFTPD Enable, But the fact is not used.
NFS Server: Shared the same partitions as in Samba.
Samba: Protocol Version SMB 2.10\SMB 3.11
It's possible that the problem with windows 10 customers' failure to connect to SMB resources is that Windows doesn't tolerate anonymous guest connections while the server does. In the event of a failure (or incorrect) authentication, the SMB server provides anonymous access without hesitation, and Windows "loses its head." It did not agree with that state of affairs and repeated the requests. The server has already "decided" - it's a guest - and gives an answer that does not suit Windows. Clinch is allowed by a reboot of samba.
Unfortunately I wasn't able to get the samba logs to see it. However, the situation seems more stable if the smb.conf make changes:
Code:

[global]
# map to guest = Bad User
map to guest = never
# usershare allow guests = Yes
usershare allow guests = No
# socket options = TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF=262144 SO_RCVBUF=262144
[MySHARE]
# guest ok = yes
guest ok = no

In the branch of the previous firmware I have already reported that excluding from smb.conf setting:
Code:
# socket options = TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF=262144 SO_RCVBUF=262144

You can avoid the kind of errors in the log:
Code:

Nov  8 18:58:27 LinkSYS kern.warn kernel: [40962.425648] ------------[ cut here ]------------
Nov  8 18:58:27 LinkSYS kern.warn kernel: [40962.430326] WARNING: CPU: 0 PID: 22115 at /home/seg/DEV/mvebu/src/router/smbd-next/smbd/buffer_pool.c:364 ksmbd_free_work_struct+0x40/0xa4 [ksmbd]
Nov  8 18:58:27 LinkSYS kern.warn kernel: [40962.443553] Modules linked in: ksmbd ext4 jbd2 mbcache crc32_generic ledtrig_usbport pwrseq_simple pwrseq_emmc ahci_mvebu ahci_platform ahci libahci_platform libahci ehci_orion sata_mv usb_storage sr_mod cdrom sd_mod xhci_pla
Nov  8 18:58:27 LinkSYS kern.warn kernel: [40962.504241] CPU: 0 PID: 22115 Comm: kworker/0:2 Tainted: G        W       4.9.241 #2174
Nov  8 18:58:27 LinkSYS kern.warn kernel: [40962.512277] Hardware name: Marvell Armada 380/385 (Device Tree)
Nov  8 18:58:27 LinkSYS kern.warn kernel: [40962.518230] Workqueue: ksmbd-io handle_ksmbd_work [ksmbd]
Nov  8 18:58:27 LinkSYS kern.warn kernel: [40962.523669] [<c011356c>] (unwind_backtrace) from [<c010ee54>] (show_stack+0x10/0x14)
Nov  8 18:58:27 LinkSYS kern.warn kernel: [40962.531447] [<c010ee54>] (show_stack) from [<c0317bf0>] (dump_stack+0x90/0xa4)
Nov  8 18:58:27 LinkSYS kern.warn kernel: [40962.538701] [<c0317bf0>] (dump_stack) from [<c01b8318>] (__warn+0xe4/0x100)
Nov  8 18:58:27 LinkSYS kern.warn kernel: [40962.545694] [<c01b8318>] (__warn) from [<c0129d78>] (warn_slowpath_null+0x20/0x28)
Nov  8 18:58:27 LinkSYS kern.warn kernel: [40962.553303] [<c0129d78>] (warn_slowpath_null) from [<bfc2e1d0>] (ksmbd_free_work_struct+0x40/0xa4 [ksmbd])
Nov  8 18:58:27 LinkSYS kern.warn kernel: [40962.563013] [<bfc2e1d0>] (ksmbd_free_work_struct [ksmbd]) from [<bfc24aa8>] (__smb2_oplock_break_noti+0x298/0x2c0 [ksmbd])
Nov  8 18:58:27 LinkSYS kern.warn kernel: [40962.574116] [<bfc24aa8>] (__smb2_oplock_break_noti [ksmbd]) from [<bfc252d8>] (__smb2_lease_break_noti+0x620/0x828 [ksmbd])
Nov  8 18:58:27 LinkSYS kern.warn kernel: [40962.585305] [<bfc252d8>] (__smb2_lease_break_noti [ksmbd]) from [<bfc26a44>] (smb_break_all_levII_oplock+0x1a8/0x2ac [ksmbd])
Nov  8 18:58:27 LinkSYS kern.warn kernel: [40962.596669] [<bfc26a44>] (smb_break_all_levII_oplock [ksmbd]) from [<bfc3abd8>] (smb2_lock+0xde8/0x1110 [ksmbd])
Nov  8 18:58:27 LinkSYS kern.warn kernel: [40962.606900] [<bfc3abd8>] (smb2_lock [ksmbd]) from [<bfc2c5e8>] (handle_ksmbd_work+0x2c0/0x474 [ksmbd])
Nov  8 18:58:27 LinkSYS kern.warn kernel: [40962.616255] [<bfc2c5e8>] (handle_ksmbd_work [ksmbd]) from [<c0143624>] (process_one_work+0x284/0x408)
Nov  8 18:58:27 LinkSYS kern.warn kernel: [40962.625515] [<c0143624>] (process_one_work) from [<c0143b60>] (worker_thread+0x3b8/0x5cc)
Nov  8 18:58:27 LinkSYS kern.warn kernel: [40962.633728] [<c0143b60>] (worker_thread) from [<c0148a8c>] (kthread+0x150/0x158)
Nov  8 18:58:27 LinkSYS kern.warn kernel: [40962.641156] [<c0148a8c>] (kthread) from [<c010ba80>] (ret_from_fork+0x14/0x34)
Nov  8 18:58:27 LinkSYS kern.warn kernel: [40962.648475] ---[ end trace 13192b3a7b0865b7 ]---

I experimented with the values: 131072, 65536, 32768,… 4096. With the last value, there are no errors either, but, damn it, the speed of copying files over the LAN corresponds to 4Mb/s. That is, it is better to just disable this line.
On the Internet, I found that the TCP_NODELAY option disables the Nagle algorithm, its purpose is to reduce the number of small packets. Apparently for my case, this is a very bad optimization.
I also tried the "dead time = 0" parameter. It is interesting that after a short time, the above error pops up again, so I returned it to "dead time = 15".
For those wishing to try:
The file is created at startup in /tmp/smb.conf - Copy it to an accessible location, for example:
Code:
 cp /tmp/smb.conf /jffs/etc/smb.conf

Add the command to the Startup section:
Code:
 stopservice samba3; startservice samba3 -c /jffs/etc/smb.conf -u /tmp/smb.db

This will start Samba with your changes without restarting the router.
And, yes, I don't know how linux clients will behave. These are my NFS connections.
I tested the work for about two days, during this time my clients never fell off. I even conducted a small "stress test": Backup - synchronization of files (about 100 thousand folders) of a shared resource to a third-party HDD simultaneously on two Windows PCs.
Later I found a number of messages in the log:
Code:


Nov 12 08:07:33 LinkSYS local5.err ksmbd: [ksmbd-worker/29261]: ERROR: Unsupported share info level (write): 502
Nov 12 08:07:33 LinkSYS local5.err ksmbd: [ksmbd-worker/29261]: ERROR: Unsupported share info level (read): 502
Nov 12 08:07:34 LinkSYS local5.err ksmbd: [ksmbd-worker/29261]: ERROR: Unsupported share info level (write): 502
Nov 12 08:07:34 LinkSYS local5.err ksmbd: [ksmbd-worker/29261]: ERROR: Unsupported share info level (read): 502


However, it cannot be said that this was caused by my "stress test" because the chronology of events in the router's log is very gnarled.

_________________
Linksys WRT1900ACSv2
Automatically adjustable temperature, always within the range of 59-68°С.
PavelVD
DD-WRT User


Joined: 26 Jul 2019
Posts: 67

PostPosted: Fri Nov 20, 2020 19:35    Post subject: Reply with quote
I'd like to show the developers my swollen log file in three days. Maybe when they see this, the gentlemen will feel the feeling and look: What can be done about it?
I want to note that during this period, Windows SMB customers have never lost their connection. I think it was affected by the disconnection of the guest access. (Previous post.)
Thank you for your attention!

_________________
Linksys WRT1900ACSv2
Automatically adjustable temperature, always within the range of 59-68°С.
Display posts from previous:    Page 1 of 1
Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Marvell MVEBU based Hardware (WRT1900AC etc.) All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum