Jump to content

lllRL

Members
  • Content count

    1,111
  • Joined

  • Last visited

  • Days Won

    13

Everything posted by lllRL

  1. I upgraded back to DumaOS today and my first game on 7ms was crispy lol. I don't know what's happening anymore ๐Ÿ˜ญ
  2. I tried again today. Same old nonsense... forced one single server and I got 2 games that were normal in around 2 hours. The weird lag is actually getting worse... it's like playing on a one bar. Had PingPlotter running alongside (obviously my PS4 had the priority with hyper lane) and it was flawless, yet in game I'm getting hitmarkers after turning 180 degrees and running away, dying half a second around corners, and just generally getting joked. The final straw came when I used this ability called FTL Jump (I don't know if you've played IW but it's like a short burst of super speed where you can fly over/past someone) over someone's head, flicked back on to them instantly on max sensitivity, engaged and got three shots off before dying (with hitmarkers after I died, naturally). The killcam shows a guy from Russia with no quickdraw on his gun, PACKET LOSS ICONS and what looked like 3 sensitivity reacting late, turning and wildly hipfiring with thumb spasm aim. The best part? From his perspective, I turned like a snail. He saw me turning on what looked like 1 sensitivity. On my screen I went over his head at the speed of light and snapped back to start firing at him before he had even turned 90 degrees, and he was firing off to my right hitting me. I was facing him a good half a second before he turned to me, yet on his screen he was the one to turn 180 degrees first on what was a quarter of my sensitivity at most. How many hundreds of milliseconds of lag would there have to be to see that much desync, with that large a discrepancy, while I'm on a 7ms ping to this server? I just don't know anymore...
  3. All I know is I lag and teleport on my own custom game host vs bots LMAO
  4. I guess hyper lane can't help my broken internet even if I've got low stable pings lmao https://youtu.be/a9RdMILcVKg Edit: why would anyone hit dislike but not say anything? All I've tried to do on this thread is help people. Weirdo ๐Ÿ’
  5. Apologies for the delay in replying. My Wireshark capture was saved on my old laptop, and I simply forgot to fish it out and load it up ๐Ÿ˜‚ I've been skimming through and the majority of the 7246 packets from this capture showed UDP (86%) with some TCP (13%) and the rest was DNS, ICMP, DHCP and TLS. Most UDP involved 3074 on one end (40040 on the other), but some UDP traffic was 3074 to 3074 - this was between players. I've been looking up some of these IPs from the single game I captured and I've seen results from ISPs (in fact the two I found were American and Omani - NICE matchmaking). Then there was TCP 3074 (me) to 64755 (Demonware in Ireland - the backend servers). The rest of it was involved TCP 443, and a few Google searches show IPs registered to Amazon AWS and Akamai, which I think has something to do with PSN. There were too many ports in communication with 443 to mention (often 60000-65535), and 443 appeared both on my end and the server end depending on what I was communicating with. Interestingly I see a lot of large packets here. TCP 3074 sent me a lot of 1494 byte packets while TCP 443 from many different sources sent me 1506 byte packets (WTF?). The largest game packets (over UDP 3074), both to and from me, were 1322 bytes. I guess that counters the claim that game packets are always tiny lol What's sad about checking all this is I've been doing my own testing with custom single hyper lane rules and I'd already been prioritising 3074 (UDP alone and then both) as well as 443, because I found out about the latter from a couple of people here on the forum. I had everything else set up optimally (70/70 QoS), small filter radius to guarantee games at either 7ms or 13ms, and games played like shit as usual. I had two random CoD games with randomly superb hit detection, and nothing was out of the ordinary in those games. My setup was the same, the server was the same... and the next game it would go back to awful again. I also used the network monitor to find the ports in use on the server end. When I connected to online services, many would pop up at once like this: ... yet when I spawned into a game, only 3074 and one other port (on the server end) would show up: So I tried adding just UDP 3074 both and UDP 37350 both to the hyper lane, but it made no difference LOL Today I got sick of seeing disgusting lag on a flat 7ms to my local server (according to the R1), and I found out that Battlefield games have different latency detection methods: the scoreboard shows ping results, and the network graph shows UDP latency for your game traffic or, in other words, your true game latency. I installed BF4, found a local empty server (based in Amsterdam) and pinged it on the geofilter. I got a stable 14ms that moved about 0.3ms in either direction. I spawned into the server on BF4, opened up the network graph and got nothing like what the R1 showed. While the R1 stayed at 14ms pretty much dead on, the in game latency fluctuated between 6 and 41ms, and spikes in game were never matched by spikes on the geofilter. Must be why I'm seeing random hundreds of milliseconds of delays on hitmarkers in CoD ยฏ\_(ใƒ„)_/ยฏ HaPpY dAyS
  6. Yeah I'm fairly sure there are one or two TCP ports involved in actual gameplay. It might be worth me looking back over my saved Wireshark captures; I only filtered out UDP for screenshots last time, but everything is in there. I'll see if I can find anything that looks relevant.
  7. I've noticed that a lot myself - I believe it has something to do with update rates if you're playing older games, as many of them have far higher send/upstream update rates (as high as 100Hz or 10 updates per second) than receive/downstream rates (as low as 10Hz). Whenever I've tested IW I see around three times as many prioritised upload packets as download. On new games like BO4 (which has 60/62Hz update rates) there shouldn't be such a difference in the number of packets prioritised both ways, so it makes sense you'd have a worse experience if traffic in one direction isn't prioritised as much. Maybe you should try download and upload sliders to even them out somehow, so while upload may be prioritised more you could level it out with less of a reduction on the upload slider? Idk, this is all speculation at this point lol
  8. Yes it already covers those. The main problem for those who want to fine tune their setup is it would cover 1024:65535 source and destination, and UDP only. This causes two potential problems: a less important port being given identical priority to the main port being used for a game, and the inability to prioritise TCP should you need to. In fact @A7Legit once did some testing and found certain games use TCP 3074 to communicate with other players and the Demonware server. Of course the preset is great for a "set and forget" approach but it may not suit players in many different games. Upload and download depends on the ports in use. If you're playing CoD and sending from 3074 to port 44000, for example, that's uploading. When you're receiving packets from 44000 that's downloading. Both are vital but, if anything, download is more important since there's zero advantage to your downstream traffic being caught in a queue; you'll simply be behind the action, trying to play catch up and dying before you see it in an FPS game for example, which affects your actions (upstream traffic) since they'll be disregarded. At least if your upstream traffic doesn't have priority you get more time to react in games where you're moving lol The worrying thing is I've been doing some testing trying to prioritise downstream only and it doesn't really seem to work. I had a rule with destination UDP 3074, source UDP 30000-60000 only yesterday and was seeing upload packets being prioritised. In fact there were far more upload packets being prioritised than down, and sometimes it wouldn't kick in at all. Frankly that's impossible since UDP 3074 is never present on the server side, and it's pretty frustrating not knowing exactly how traffic prio is doing what it does. The reason I want to test this is because classified games and the PSN preset do nothing for my experience in games. I've only had brief success trying custom rules.
  9. I've used a variety of setups with my R1 over the last few years. I've used ISP combos which usually don't have bridge mode or any ability to run as a pure modem, I've used a TP Link model which can run as a modem only, combo or router only, and I've used the Huawei HG612 in bridge mode only since it doesn't have WiFi and wouldn't be worth using in router mode. I've also been with Virgin Media whose Superhub let me use bridge mode with no other configuration - it was as close to "plug and play" as you could get. A few months ago I moved from BT to TalkTalk - an identical service except for the fact that BT uses PPPoE (1492 MTU and requires login info) and TalkTalk uses IPoE (1500 MTU and "plug and play"). The BT Hub didn't have bridge mode so I could use that as a combo behind the R1, or I could use a pure modem behind the R1 and enable PPPoE on the R1 to get online. When I first moved to TalkTalk I tried out all possible setups and since it's not PPPoE you should just be able to connect the R1 to a pure modem and be on your way, just like I could on Virgin Media cable with the Superhub in bridge mode. This was the case with the HG612 (set to IPoE_bridged or whatever it's called) where the R1 would now be the only device handling NAT etc, with its own public WAN IP. If I set up the TP Link in bridge mode, as I could easily do with the R1 before, I wouldn't get a connection on the R1 and I'd be stuck with either a local IP or none at all. TalkTalk doesn't use PPPoE but I tried enabling that on old firmware and DumaOS, with the fields left empty, but no bueno... Today I decided to see if I could figure it out, since the TP Link is my favourite "modem" and it runs better when in bridge mode. I inadvertently found a fix when I came across a post on this forum from a guy trying to work out a different problem on TalkTalk, where he could already use bridge mode on the other combo TalkTalk provides (mine is the new WiFi Hub): In the post he mentions a guide saying he should "disable DHCP in the LAN", which seemed weird to me because I'd have assumed DHCP would be disabled in bridge mode. I was extra confused because I didn't need to do this on the TP Link when running it in bridge mode. Anyway I decided to try it myself after enabling bridge mode on the TP Link and, lo and behold, I now have it working just fine with TalkTalk and the R1. As expected I don't need to do anything else on the R1 since TalkTalk is IPoE and not PPPoE. I just rebooted the R1 once and the old local WAN IP was replaced with a public one - something I could only achieve in bridge mode with the HG612. The only downside is I can no longer access my TP Link GUI; on BT I could simply disable PPPoE on the R1 and I'd be able to access it through an R1 WiFi connection. Not that big a deal really lol Bit of an essay but I'm half thinking out loud, half wondering if any of you know why this only works if I disable DHCP on the TP Link when it's already in bridge mode. I wanted to write this as a kind of guide in case anyone else has any issues themselves with such a setup. Someone browsing the forum or even searching for answers on Google might get some use out of this if they stumble across it. Cheers and Happy New Year
  10. Thanks... lol There are different settings between the two that don't translate. With the HG I think you can use ipoe_bridged (or is it just ip_bridged?) which sets it all up fine with no other tweaks required. That's why factory resetting gets you straight online. None of those other settings (like 802.1p/q) are on the TP Link, other than VLAN which is obviously 101. There's even a drop down menu on the TP which asks for your ISP (there's an option for TalkTalk_VDSL) before you enter bridge mode. The VM Superhub definitely didn't require my turning off DHCP on it to get it working in bridge mode with the R1 - you just enabled it and away you go ๐Ÿคจ
  11. I'm not using a HG612 lol. I have no issues with that. It's the TP Link I couldn't bridge before.
  12. Hey. I know they're different to an extent (IPoE vs PPPoE) but my confusion lies in what I had to do to get it working; the differences between the two ISPs should be irrelevant in this case. The VM Superhub in bridge mode was plug and play with the R1, and while I had to enter PPPoE info on the R1 with BT I didn't have to disable DHCP. I mean, if it's in bridge mode it's not handling DHCP anyway right? How very brain bending ๐Ÿ˜‚
  13. As far as I know 9307 relates to party chat and 9308 is just what you need to connect to PSN in the first place - perhaps prioritising 9308 could help with the overall experience on any game. Let me know how it goes for you ๐Ÿ‘ Tip: remember to use the tag feature on Wireshark to make it easier to sift through packets. I typically just type in UDP since I'd be looking for stuff relevant to CoD, but I have also used it to check info on ICMP pings after using PingPlotter before. When you reach the first screen of Wireshark, before you double click an adapter to start a capture, check the IP of that connection. If you're bridging it shouldn't be 192.168.88.x like most devices connected to an R1 (does the XR500 have the 192.168.88.x range too?) might be, for example, but it would still show up as a local IP. Mine here was 192.168.137.136: If you identify that and then the server you're connecting to, you can click either source or destination at the top and order your packets so that only one direction of traffic is visible at a time, just to keep things tidy and easy to flick through. You'll notice I also have the UDP filter applied (make sure to hit the arrow just to the left of "expression" at the end of the bar to apply). Another tip: at the top left you'll see a blue fin or a red stop icon; one will be greyed out depending on whether the capture is running or has been stopped. When it's running you'll see a total number of packets captured at the bottom right of the screen, and which percentage of those are visible if you have a filter applied. If you stop the capture and delete the UDP filter to display everything again, the packet counter on the bottom right will now show you if you've had any packet loss at any point during the capture
  14. Huh, no need. After many many hours of constantly trying it finally prompted me for my username and password and let me on. Big fat question mark? ๐Ÿ˜‚
  15. Hopefully all of this talk on the subject will keep Kinel's thread bumped for visibility and encourage more votes. It's truly a great idea ๐Ÿ˜
  16. I'm afraid I haven't mate. According to my old XBL profile's "recent players list" or whatever I haven't played Halo since 2008 LOL. I just did a search online to see if I could find any netcode analyses done on it but couldn't find anything ๐Ÿ˜• unless you figure out what it's using through trial and error you might need to use Wireshark yourself. The bridging process just means getting a PC or laptop in between your XR500 and console (I'm assuming you're on console anyway... if you're on PC it's so much easier as you simply open Wireshark lol). If you have a PC you might be able to use two ethernet cables in the setup, but since you're only checking it for port usage and connecting quality isn't important, you can just connect your laptop or PC to the XR500 and run a cable from laptop/PC to console, or vice versa. Bridging is as simple as highlighting the two adapters in the Network & Sharing Centre and right clicking to get the option to "bridge connections". You'd hit change adapter settings here on the left: Then find the appropriate adapters here: For me, I would left click Ethernet, press and hold shift on the keyboard, then left click WiFi. Once both were highlighted blue I'd right click and hit bridge connections, and voilร  I found it easier to connect my laptop with WiFi and then run a cable to my PS4 and set that up with a wired connection, because I'm used to seeing Ethernet with a moving "traffic bar" in Wireshark when scanning interfaces. Bit confusing because I just said Ethernet, but here you'll see the correct interface (with traffic movement next to the interface name) and for this image that's WiFi. It's only because these are the only screenshots I've got on my phone as I tried to help someone else here use Wireshark with screenshot tips you'll see the little squiggle anyway, while everything else is flatlining: If you can't be bothered with all that, I guess you could just start tinkering with port numbers under traffic prio until you see the red light pop up lol
  17. I have no idea. You'd have to ask the Netduma team how they determine which packets are identified as related to gaming and what the preset does once it's identified them. I'd assume any port (1 through 65535, TCP and UDP) could be identified as relevant to gaming depending on whatever you're playing, and it would prioritise them accordingly. Or it might only prioritise upstream traffic ๐Ÿค”
  18. I've always been able to access the DumaOS GUI with either R1, http://r1, 192.168.88.1 or one of the full links like the above. "R1" seems tied to DumaOS whereas links with "cgi-bin" are for the old firmware, like this: I already had the time limit set to the max of 7 days but I can't get into network settings or any other page now anyway ยฏ\_(ใƒ„)_/ยฏ I should add I've never had any issues with IPs before, regardless of whether the settings are default or customised with a longer or shorter time limit, smaller IP range or manually allocated IPs, so I doubt that would be the cause.
  19. In this case 3074 source and 30000-60000 destination would be upstream/outgoing traffic, whereas 30000-60000 source and 3074 would be downstream/incoming traffic. That's what this setup would cover in full: The classified games setup automatically detects game traffic but we don't really know what that includes, and it could well be prioritising less important ports and giving them equal priority to more vital ones. This method just allows us to have full control.
  20. That could be it. I've never seen that before but it makes sense. It's not that big a deal though since there isn't much you can save with cookies anyway. I haven't tried accessing the GUI with anything other than the links I already have in my history. For example if I type in QoS, 192.168.88.1/desktop/index.html?cache=0#com.netdumasoftware.qos pops up and that's what I've always got onto the GUI with. It still doesn't explain why I couldn't get a connection through the R1 though ๐Ÿค”
  21. Either works really, as long as UPnP or port forwarding (or DMZ if you need it) gets you an open NAT. Ports like the 30k-60k range for CoD don't need to be forwarded for you to be sending/receiving packets over them. I daresay you only need 3074 forwarded because that's the port you connect to other players with through the Demonware matchmaking server (although sometimes it appears TCP 3074 handles this too). Game traffic still appears to pass through 3074 even if you don't have an open NAT.
  22. My pleasure. Most will prefer to just pick a preset and forget about it, but I know there are quite a few tweakers here on the forum lol. I was only inspired to take a deeper look into it once I read Scrizzy's old post asking for help with customising rules for hyper lane, and once I learned more about how networking works on CoD I learned how to find out what was going on in our games with Wireshark. I don't think I'd have gone to such lengths if it wasn't for A7Legit's swearing on hyper lane making all the difference with the quality of his games! Of course if you can find just one or two ports that are vital to the experience we have in games, it makes sense to place a higher priority on those than any others. If anyone here wants to do the same kind of testing, it's a piece of cake if you're on PC. If you're on console, you just need to bridge your connection from R1 to console through a PC by going to the Network & Sharing Centre, clicking change adapter settings and then left clicking one your ethernet adapters (or WiFi if you're using both), pressing shift and right clicking the other to give you the option to "bridge connections". Then you just download and open Wireshark, wait for it to scan for interfaces, and click on whichever connection leads to the console in use. It's a pretty cool trick for those like me who enjoy in-depth testing. Before I'd even heard of Netduma, I used this in AW to figure out why connections were atrocious when Sledgehammer Games claimed "ping is king". Wireshark proved I was spending most of my time connecting to the Seattle server on the west coast of the US, which speaks volumes when you live just outside London. Of course if I had a Netduma, it would have been a tad easier getting that proof
  23. Weird. I rebooted my router yesterday (I started having a weird issue with moderate NAT when my R1 has the same, single possible WAN IP from my ISP hub and is still in its DMZ with my PS4 having the same IP and same forwarded ports) and when I just went back into the GUI, I was getting those tip pop ups for certain features again - those I'd already ticked don't show again for. On the geofilter page auto ping host was ticked (I unticked it yesterday after realising checking the ping to the server was futile) and my zoom setting wasn't staying put. Ping assist was the same though... Anyway I just deleted the PS4 from the filter, flushed the cloud, reset my ping assist back to 8ms (just to check it'll be working, since it should be pretty obvious at 8ms) and readded the PS4 to the filter. I'll report back in a little while when it's late enough to find a decent number of games. I wanted to keep testing yesterday but every game was giving me packet loss icons and lag spikes of hundreds of milliseconds while the geofilter and PingPlotter said I was maintaining flat low pings and zero packet loss. I swapped cables between the PS4 and laptop, and PingPlotter still showed no packet loss to these IPs while I still had constant icons in game... And those were the two best games of the morning LOL. Same thing was happening against bots in custom games but without the icons... Icons are unusual for me. When games were at their worst for the most part of two years, before switching from BT to TalkTalk, I never saw icons unless I was in custom games or the online game I was playing was player hosted. I had never seen them playing on servers before. I got on yesterday to keep testing since I was finding one good responsive connection every 200 games on the same single server if I was lucky, but now apparently there's some form of packet loss in the mix too. I turned off my geofilter, disabled QoS and deleted traffic prio rules yesterday and I'm immediately thrown into the most normal looking game I've had for months? No icons? Same 7ms server, with a connection that actually felt like low latency... Maybe it's time for me to start testing without the R1 after all this time โ˜น๏ธ Edit: wow, it just occurred to me... while that one game was amazing in relation to the others I've played lately, there was still a good 90-120ms delay on shots registering. That's wild hahaha ๐Ÿ™„ in my "typical" game on the UK server for example, it's normally a good 10-15 frames worth of delay (167-250ms) with it getting exponentially worse if I play on a server further out. Ironically my most responsive games used to play out on servers based in countries like Denmark and Poland, with instant local game like hit detection, but sadly I was never able to take full advantage of the R1's best feature to force those lobbies more often because for some reason they were rarely populated. The UK and French servers always seemed to act as black holes for anyone between Ireland and Pakistan ๐Ÿ˜‚ Edit: nvm, nothing is wrong with my R1 now. I was on my PS4, sending someone a message and screenshot and it said I'd lost connection to the server. Eventually the WiFi icon on my phone got the x next to it indicating there was no connection. I tried setting up my PS4 network again and it wasn't going through. I thought there must be something up with the modem or it was rebooting itself, but the modem network light was on. I switched on its WiFi and all was fine again. So I went back to the R1's WiFi on my phone to connect to the GUI and all it says is this: I can click the buttons down the left hand side (nothing happens, the same message remains on screen) but I can't click those at the top to reboot/reset/upgrade. So I pulled the power from the R1 and when it turned on and I reconnected to the WiFi, there's still no connection. Edit 2: I used the pinhole reset button and apparently I'm back online but the GUI is utterly broken. It just doesn't respond to anything and I still have this message despite getting a connection again: As you can see the x has gone but the GUI is unusable. Please help... I'm losing the will to live ๐Ÿ˜ญ
  24. I'd recommend finding out which ports are in communication with 3074 on the server end. 3074 is only one half of the equation, because that's only the port used on the console (not the server). I've only ever tested this for BO3 and IW for myself, but the server port is usually between 30000-60000. However Battle(non)sense's netcode analysis videos for WW2 and BO4 also show that a port from 30000 onwards is still used on the server end: Anyone here on the old Netduma firmware can confirm this by connecting to online services and clicking on the bandwidth bar spikes for both downstream and upstream traffic on the network monitor like this: I recommend finding out the appropriate range of ports like this because setting up a rule like src 3074 dst 1-65535 only covers upload traffic, and if you try to set up two rules (3074 as src 1-65535 as dst and vice versa) traffic prio will say failed to install because lanes overlap. However if you set up rules like this it works just fine, meaning you prioritise two way traffic: Then just make sure to test it works because getting the light to come on is wonky at times. I've previously set up a rule for downstream traffic only and it refused to work at all, which doesn't make sense considering 3074 is constant as the destination for us when downloading and as the source for us when uploading. Also here are some Wireshark captures from my own testing on CoD, showing port 3074 on the console end in communication with ports in the 40000s on the server end:
  25. Nope, I set mine up before I get on. I rebooted the R1 and reloaded the game but still, people all over the world were getting these ping assist icons. There was one lobby search where everyone outside of my radius was correctly marked with one of those exclamation mark triangles, but only one.
×