ChrisG82

I find this statement very daring! I took a look at the website as of 10 December 2023. All technical specifications are fully disclosed here. Directly on the pre-order page. All you had to do was scroll down a bit. And sorry, if you really didn't see that and bought the router blindly, you can't blame anyone for that.... And if you don’t believe me, here you can proof yourself: web.archive.org

Explain to me why you need more RAM and more CPU power? If the software is developed on this hardware specification, it will run. And apart from the bugs, it does this without any problems. If you take a look at the statistics, you'll see that the processor is currently bored for the most part. One core is even completely idle. RAM is never more than half full. So why do you want more performance so that it lies idle again and you spend money unnecessarily? Sorry, but that's like complaining that the car only has 200 instead of 600 horsepower when all roads have a speed limit of 120 KMH anyway. The only point where I agree with you is that a 2.5 GB port would have been nice

Ah, okay. Yes, the switch gets an IP just like any other client. You can use it to access the web interface. Then you have to specify which port should be mirrored. look here: Manual

When I buy a gaming router, I expect it to primarily offer gaming features and not business features. Everything else is a bonus.

Not really. Port mirroring is a function that is needed more in the business sector than in the gaming sector. And as already recommended, if I were you I would simply get a small switch from Netgear, for example, and connect it between R3, PC and PlayStation. The GS105Ev2 would probably be enough...

@BadLuckTom I would rather say from the customer's point of view it would be better if Netduma didn't try to fix so many problems once per update, but simply released versions at regular intervals, with which perhaps only one or two problems are fixed. In the end, it still takes months to fix all the problems, but not all customers have all the problems. I think such an approach would ensure a lot more peace and quiet here in the forum.

Disable it on WAN and LAN.

@Netduma Fraser Do we have to worry about the fact that you wrote on 1 April that it won't be long until the new firmware is released? Because of April Fool's and so on…. 😉

If I were you, I would first deactivate IPv6 again. There seem to be more frequent problems with this at the moment. What kind of device do you have connected to the Ethernet port? Perhaps you should simply make an IP reservation for the device in R3.

Mine R3 says up to Date….

Then you don’t know the „Blizzard soon“

Yes, here in Germany too. But it could have been that the firmware is already ready and will be released automatically on Sunday or Monday. In any case, I wish you and the team a happy Easter and hopefully a few relaxing days.

Hey @Netduma Fraser. What are the chances that we'll get an Easter present from Netduma in the form of a new firmware version for the R3?

@cljackhammer I don't think we'll have to wait much longer for the new firmware. Last Saturday @Netduma Fraser posted a changelog. I suspect we will get the new firmware within the next 2-4 weeks. Here is the post: https://forum.netduma.com/topic/54660-in-1-week-it-will-be-2-months-without-any-new-firmware-and-there-are-so-many-bugs-and-problems-still-unresolved/?do=findComment&comment=405292

It might be a good idea to contact your ISP's support team. They will certainly be able to tell you what is required for the R3 to be able to establish the connection. I could imagine that the ISP will need the Mac address of the R3 anyway.

That's sarcasm, right? WiFi is not a new technology and yet the R3 has massive bugs there. Routers themselves have been around for decades and yet the R3 has bugs in standard functions. I think that far fewer people would be writing here if bugs were only present in functions that make the R3 truly unique, such as the geofilter, the ping optimiser and so on. However, the R3 currently also has problems with simple standard functions that have existed with every other manufacturer for decades. Nobody here wants to badmouth the R3. But unfortunately, Netduma really wanted to have the R3 on the market before the 2023 Christmas season. I think it would have done the R3 more than good to simply delay the market launch by six months in order to eliminate the aforementioned bugs or finalise the advertised features so that they are actually available on release...

I have only reduced the MTU in the advanced settings. If I now (like you) send an ICMP to Google, for example, and set the packet size manually, I just don't get above 1464. Of course, only if I also say that the packets should not be fragmented. EDIT: So here are two screenshots, one with a registered MTU of 1492 and one with an MTU of 1450. The first ping per screenshot is directly against the R3. Here you can see that the LAN side is not affected and accepts packets with 1472 bytes without any problems. However, as soon as the packets go out via the WAN interface of the R3, you can see that the packets are limited in size. Depending on the MTU in the R3 settings (And no: I have not changed any settings on the client itself)

The way I see it, he doesn't have a simple ONT. In his case, ONT and modem are one and the same device. At least that's what you can find on the website of his ISP

@bayleeshymko Have you tried making a trace route to Google? What is the first hop after the R3?

Have you actually read other threads or do you only ever read your own? @Netduma Fraser has already mentioned often enough that the speed test they have integrated is currently not really meaningful, as it simply fluctuates too much. This is not due to your setup or your line, but may simply be due to the server against which the R3 measures the speed. Why don't you just load a different speed test onto one of the devices that run via the R3? For example, the speed test from Ookla and just do your tests on that? Here you even have the advantage that you can set the server you want to test against, so that the test always runs against the same server. Please note, however, that the results may fluctuate slightly depending on how busy the server is. Please don't forget to activate the bypass for external speed tests in the settings beforehand.

Yeah, no problem. But I still don't understand exactly why it works for me and not for you. The only difference is that my R3 establishes a PPPoE connection and you use DHCP. If I reduce the MTU in my advanced settings, all clients are affected. They then can only send packets with the DF flag that comply with this maximum MTU and without the DF flag the packets are fragmented accordingly... And I think this behaviour is completely correct. Because with this setting I tell the R3 that it should only send packets up to a certain size to the outside via the WAN interface. So here is my request to @Netduma Fraser Please clarify with the devs what behaviour is really desired when the MTU is changed in the advanced settings.

@Fuzy @Netduma Fraser I think he wants to avoid packet fragmentation. And yes, of course a PC on which an MTU of 1500 is set uses this for the packets. However, if the packets are to be sent to the Internet via the WAN interface of the R3, packets that are larger than the set MTU should NOT be processed if there is a DF flag on the packet. But this is apparently not the case with him. And in his example he has actually shown that he is sending an ICMP packet where he specifies the size manually. If he has specified an MTU of 1492 in the advanced settings in R3, no packets with a DF flag that are larger than 1464 should go out. For me it works as it should. The question is whether it does not work for him because his connection runs via DHCP and mine via PPPoE So I can only imagine exactly two things that could be the cause. Either the R3 ignores the maximum MTU set for a connection via DHCP or he has not connected his ISP router to the WAN port of the R3.

So you're saying that giving technical details about a problem that apparently only you have doesn't matter? Okay, then it looks to me like you're not seriously interested in troubleshooting. It works completely problem-free for me. So it doesn't seem to be a general problem and only occurs in certain cases. But I'm sure you'll find out eventually.

Ok let’s ask me again: what type of internet connection you use?

I have tested it in my network. My MTU is set to 1492. The maximum packet size for me is then 1464. From a packet size of 1465, the ICMP packet no longer goes out. So the limitation actually seems to work. PS: my R3 establishes a PPPoE connection.