-
Posts
161 -
Joined
-
Last visited
-
Days Won
1
Everything posted by ChrisG82
-
I don't need to understand your answer, do I? First you say I'm wrong and then you write yourself that the chipset can do MU-MIMO (even if only downlink). So the statement is still correct: The R3 can do MU-MIMO in terms of hardware. Just as it is capable of uplink and downlink OFDMA in terms of hardware... If Netduma states to the FCC that it is a router with MU-MIMO functionality (which they seem to have done. Otherwise it wouldn't be so emphasised on the user manual) I assume that this feature is also used... EDIT: However, all these discussions are of no use as long as Netduma does not even clearly state which features they want to implement on the software side in the future, or have already implemented.
-
These are the documents that Netduma submitted to the FCC for approval of the R3. They may have made changes afterwards, but I think that the router is still capable of MU-MIMO. Without FCC approval, Netduma would not have been able to launch the router on the market at all… PS: if I am not mistaken, a hardware change, such as the omission of MU-MIMO, would invalidate the approval, so that the router would then have to be re-registered for approval
-
The R3 sholud support MU-MIMO Look HERE: FCCID.io Netduma R3 Manual
-
What did you see when you look in R3 under Stettings —> WAN?
-
Ping Optimiser does not calculate correctly
ChrisG82 replied to ChrisG82's topic in Netduma R3 Support
I know that my maximum bandwidth without restrictions is around 270 Mbps for downloads and 43 Mbps for uploads: If I switch on the bypass, I have that too. If I switch off the bypass, I am limited by the congestion control. According to the setting, this should be 99% of the bandwidth. So I would be missing 1% of the bandwidth. But 10% is missing Set the congestion control manually to 50%, 60% is missing As I understand the function, it is there to limit the bandwidth so that there is still enough bandwidth left so that the latency is not affected if something wants to load with full bandwidth. The bandwidth itself is determined by the setting in the speed test. -
Ping Optimiser does not calculate correctly
ChrisG82 replied to ChrisG82's topic in Netduma R3 Support
-
Ping Optimiser does not calculate correctly
ChrisG82 replied to ChrisG82's topic in Netduma R3 Support
I tried the following again: I simply entered the download value of 200 in the speed test and set it to 50% in the Conquest Control. I was then only able to use just under 90 Mbits of my bandwidth. -
Ping Optimiser does not calculate correctly
ChrisG82 replied to ChrisG82's topic in Netduma R3 Support
The congestion control values therefore specify the percentage of the maximum available bandwidth (determined by the speed test) that may be used so that the latency does not deteriorate. However, I determined this morning that the bandwidth is restricted about 10 % too much as specified. -
I took a closer look at the Ping Optimiser today and noticed that it throttles more than the percentage indicated. The test setup was as follows: R3 freshly restarted Optimisation performed with Ping Optimizer Congestion control was automatically set to 99% for both upload and download Client connected directly to R3 via cable Speed test used: Speed Test App from Ookla with fixed server (so that the results obtained are reasonably comparable) Maximum speed determined with "Bypass" switched on in the Speed Optimiser: Performed several tests and achieved the following speeds on average: Download: 270 Mbps Upload: 43 Mbps These values are then entered manually in R3 ("Speed Test" -> "Advanced Speed Settings") Then deactivated the bypass in the Ping Optimiser and carried out several tests again, which resulted in the following average speeds: Download: 238 Mbps Upload: 38.4 Mbps The maximum download speed was therefore limited to around 88.15 % and the upload speed to around 89.3 %. The Ping Optimiser therefore appears to have reduced the speeds by 10% more than specified by "Congestion Control" (throttling to 89% instead of 99%) I then simply changed the values in the "Advance Speed Settings". Here, too, the difference of approx. 10 % remains. Set: 300 Mbps Achieved: 265 Mbps (Just a reminder: with bypass, the maximum speed is 270 Mbps) Can you please check whether the firmware is really just calculating incorrectly? PS: I can provide screenshots if required.
-
Okay . It's quite possible that the whole thing may have been misunderstood on both sides due to the translation. The important thing is that everyone now knows that the IP should not change. No matter which variant the user thinks is most suitable. 😉
-
He may be a moderator, but his statement was simply wrong. It is not necessary to give devices a fixed IP. In other words, to store the IP configuration directly in the individual client. It is completely sufficient to set a DHCP reservation in the router for the corresponding devices. And above all: I am not being condescending. I merely corrected a statement that was incorrect. And the fact that I offered help was not condescending either, but really just that: an offer of help. The task of moderators in a forum is usually only to ensure that a pleasant tone prevails, to remove posts if necessary or to warn or remove users. A moderator on a forum does not necessarily have to be technically versed in the subject matter of the forum.
-
Ahh and one more tip. If you are using an iPhone/iPad, don't forget to deactivate the "private WiFi address" function in the WiFi settings for your network. Otherwise you will soon have various devices in the R3 Device Manager with different IP addresses, as these devices will then always log in to the R3 with a different Mac address.
-
Have you possibly stored a manual DNS server on your devices? Or do they obtain the complete settings via DHCP? Can you perhaps send a picture of the IP addresses that your device has received? I have added a screenshot of my iPhone as an example.
-
But you are able to connect to them?
-
Can you post a picture of the R3's WLAN settings? Not that channels have been selected that are not supported in Japan. So connect to the R3 again via the browser on the notebook and then go to the following point: Settings -> WiFi -> Advanced It is best to select Split WiFi here first. It will then take a moment until the WiFi is available again. You should now see the 5 GHz and 2.4 GHz network with two separate SSIDs. Then you can try connecting to both SSIDs and see if the problem is at 2.4 GHz or 5 GHz PS: you can leave or set the password identical for both SSIDs.
-
Okay, let's try it another way: Do you have a notebook or PC to which you can connect a network cable? If so, please connect a cable there and plug the other end into a yellow port on the R3 and (leave the connection from the R3 to your router as it is). Then start an Internet browser and enter the following IP address in the address bar: 192.168.77.1 This should then lead you to the R3 setup wizard.
-
Do you have the option of connecting to your router and checking whether the R3 appears as a device and what IP address it has been assigned? Or can you connect to the R3 with the notebook via cable? If so, the notebook should get an IP address from the 192.168.77.X range. Then you can open a browser and simply try to call up the address 192.168.77.1.
-
Sorry, but unfortunately you didn't understand what I wrote: DHCP reservation So there is no more lease time and the client ALWAYS gets the same IP from the router.... PS, if you don't know this, it's no problem. I can explain to you where you can find and set this up in R3.
-
Sorry, but that's rubbish. Of course DMZ and port forwarding also work with a client that gets its IP from DHCP. You just have to make sure that it doesn't change. And that works quite simply via DHCP reservation. Giving the client a fixed IP address is absolutely unnecessary.
-
The purpose of a VPN tunnel is to transfer data from point A to point B in encrypted form. It is therefore normal that nobody can see in there If hybrid VPN is available on the R3, things look different again. The R3 should be able to classify the data before it sends it through the tunnel, as it sets up the VPN access itself.
-
I would rather say that one of the two adverts is simply wrong. They will be the same servers.
-
Hello dear NetDuma team. Here are my thoughts on NetDuma R3 and DumaOS 4 after about a week of use. Hardware: The R3 has a USB port which is currently completely unused. Please give us the option of using a USB stick there to persistently store all LOG data (system logs, ping shedule log, network activity, adblocker, etc.), which is currently lost with every restart / power cycle. Especially for the system logs and the network activity it would offer a great added value Software: GeoFilter: It would be nice to be able to customise the name for a server directly after selecting it in GeoFilter and not only in the list for the shared/locked servers. In DumaOS 3, not only a meaningless ID for the server was visible, but also IP addresses/host names. Please implement this in DumaOS 4 as soon as possible. This is particularly interesting for troubleshooting via traceroute and so on. It would also be nice if a traceroute function could be implemented directly. This would be very helpful to see directly whether the server itself is running badly or the peering of the ISP is simply bad. Ping HeatMap Enabling or disabling servers via the Ping Heat Map would be ideal. It would also be nice if you could provide a list of hosts/server IPs per country directly there. A direct traceroute function would also be highly desirable. Network Activity: Saving the data on a connected USB stick so that it can be reloaded and displayed after a reboot. Unfortunately, it is useless if you have to restart the device more often and these statistics then simply start from scratch. A quick implementation would be desirable here! Device Manager: Delete Offline Devices: As soon as you have made adjustments to a device such as name, DHCP reservation, QoS etc., these devices must be deleted. These devices must be excluded from the delete function! It is no use simply deleting such devices when you want to tidy up! This should actually be a matter of course! A ping function for internal devices would be desirable. Ideally with an audio output. This would be very useful for identifying unknown devices. Audio output should then of course stop if the ping is not answered. A possibility to make suggestions for new categories directly from the Device Manager. Possibly enable manual categorisation by allowing the category to be named and providing a large selection of pictograms. For unknown devices, it would be nice to be able to perform a search via a MAC database so that at least the manufacturer of the network module is displayed. This would make it easier to identify unknown devices. Currently, devices that are connected via a wireless repeater are apparently not displayed individually in the Device Manager. You only see one device there, which then contains all IP addresses. This means that the devices behind the wireless repeater cannot be prioritised, restricted, named and so on. I think this is currently a serious bug that needs to be fixed as soon as possible! Speed test: It should be possible to schedule speed test for automatically testing (as with the ping heat map). Since certain functions depend on knowing the real upload and download speed, it would be a great advantage if the R3 could take care of this directly. You might want to consider choosing a partner like Ookla for the speed test. It would be a great advantage if I could choose the server I want to test against. Ping Optimiser: If you implement a time-controlled speed test, it would be nice that if the speed deviates too much from the last optimisation of the ping, it automatically performs a new optimisation with the current measured speeds. Guest WiFi: I don't really understand your concept of guest WiFi. Not only does it use the same subnet as the normal WLAN, but the devices in the guest WLAN can also communicate freely with the devices in the normal WLAN. This makes the idea of a guest network absurd. Please introduce a separate subnet here as quickly as possible. Maybe with the possibility to allow (single) devices from the guest network to communicate with the normal network. Devices that are connected to the guest network are currently not displayed. Please also display these in the Device Manager. Preferably with a small symbol to make it clear that these devices are connected to the guest network. All devices in the guest network should be included in a "Guest" group so that I can restrict from the outset what the guests are allowed to do (surfing only, peer-to-peer downloads, FTP, SSH, etc.). Unfortunately, I have to say that as long as this is not implemented, the guest network harbours more danger than benefits.... UPnP: UPnP is active by default in DumaOS. This harbours a certain potential for danger. It would certainly be more favourable to set UPnP to deactivated by default. It also appears that I can only activate or deactivate the whole thing. Here it would definitely be better to be able to decide which clients are allowed to use UPnP and which are not. Currently I have not found a way to specifically delete entries in UPnP. This should also be possible. Port forwarding: Perhaps you would like to provide a list of frequently used services/games for port forwarding. This would make it easier for simple users to set up port forwarding. I envisage this in such a way that the device can first be selected via a wizard (as is the case now) and then the corresponding games can simply be selected. You can then set up the corresponding forwarding via a database. System Info: It would be nice if a manual firmware upgrade could be carried out from this menu and not from the troubleshooting menu. Troubleshooting: It might make sense not to put the system logs in the Advanced menu first. The time period for the CPU load is far too short. For proper troubleshooting, it must be possible to display the CPU utilisation for at least the last 24 hours, if not a week. It is also a good idea to only do this when you have connected a USB stick to save the data. The CPU temperature would certainly also be interesting! And last but not least: Please introduce an option to save the configuration as quickly as possible! This should really include all manual settings such as Internet connection, network and WLAN settings, DHCP reservations and so on. It is absolutely unacceptable to spend hours on the configuration only to realise that you have to reset the device again due to an error in the firmware and then start again from scratch. Of course, this would also be helpful for future firmware updates. If you perform a backup before the upgrade, you can perform a factory reset after the downgrade and import the appropriate config for the appropriate firmware. This can also be combined with a forced backup before each update. So. I know it's a lot of text, but in my opinion there are many ideas for making the R3 and DumaOS 4 even more powerful and useful. Greetings from Germany
-
Nein, den Bridge Mode hat AVM bei aktuellen Geräten wegrationalisiert. Bei älteren konnte man den wieder aktivieren, indem man die Config Datei modifiziert und wieder hochgeladen hat. Ist aber auch seit einiger Zeit komplett aus der Firmware entfernt. Aber der TP-Link macht seine Sache als Modem bisher hervorragend. Upload, Download, Latenz und Stabilität sind bisher identisch zur 7590. Kann mich also überhaupt nicht beklagen. Für knapp 61 € hervorragend.
-
@kevwhite Thanks for ur fast response. I will try it. (but first i will try without the Wipe)… EDIT: Unfortunately, it seems I wasn't so lucky. But as already announced, I didn't do a factory reset either. Could you please check which network your doorbell is connected to and which network the device you are using to access the doorbell is connected to? Are they both connected to the same network? So 2.4 or 5 GHz? You should be able to see this in the device overview.
-
That sounds very interesting. I got my R3 with the .21 firmware and immediately upgraded to .41. At the moment there are problems that various devices are not reachable if they are on the same frequency. For example, the printer uses the 5 GHz network and the iPad also uses the 5 GHz network. The printer is then not recognised by the iPad. Or the TV use 5 GHz and the iPhone with the Control App use 5 GHZ to. The Controll App is not reaching the TV. When the iPhone switch to 2,4 GHz then all works normal. @kevwhite How is it currently working for you after the downgrade and upgrade? Did you have such problems to?