Jump to content

xr500user

Members
  • Content count

    126
  • Joined

  • Last visited

  • Days Won

    1

xr500user last won the day on January 6

xr500user had the most liked content!

About xr500user

  • Rank
    Member

Recent Profile Visitors

265 profile views
  1. lol, reported this since day 1 of .40 firmware, also sent all my findings to NetDumaAdmin. Hopefully not falling on deaf ears? bug in duma os. network monitor not effected
  2. xr500user

    [DoS Attack: Ascend Kill]

    seen this from time to time from google dns also, mostly happens on router first boot. mis-identified dos attack
  3. i would shoot for having it on if everything is stable, as everything works better when its on (unless its not working and causing you issues of course) if you turn it off then you lose the ability to see what the breakdown of the traffic is in network monitor area (which only seems to show the top 5 consumers at any one time, if a device is not there and you have more then 5 devices on your network - this doesn't mean its not working, and doesn't see the device, it just isn't consuming enough to be in the top 5) when qos is on you can click the upload or download bars on the device in network monitor and it will open a breakdown to the right of it of what it thinks the traffic is (games, media, web, etc) and if you go one step further and click on the color on the circle it will show additional breakdowns. if you click the upload and download bar on total usage line (first on the list) -overall usage- you can see breakdowns like what apps overall are consuming when you click the color on the circle that you want to see (twitch, bittorrent, SSL traffic, apple, microsoft, ssl, media streaming, youtube, netflix, etc) when its off, this info will just be unknown traffic. qos tries to prioritize whats more important and should go before someone else , in a perfect world it works. it classifys and then marks certain connections with priorities and if the connection for example say is thought to be offline in another module, for whatever reason (a monkey) you know we have an issue here , sometimes these classifications stick, even through a reboot and some chaos starts, combined with the dhcp thing, etc it could be a mess quick.. you wanna know why nobody else is doing what they are doing - this because its a real pain in the ass and pretty difficult to get it to work for everyone and every network scenario, but credit goes where credit is due they are the only one this close to perfecting it upnp is another animal, netgear always had issues with it in one form or another (reporting wise), upnp is supposed to open ports for you automatically so you don't have to do the port forwarding. but the requesting application is thought to be trusted if on the local LAN so it goes ahead and opens the port in the iptables firewall on the router.. and after a certain time its supposed to remove it, just because it shows there its most likely to be closed if after the limit..as other things on the kernel take care open connections that should not be lingering. its the upnp daemon netgear chooses just not updating its upnp_pmlist file (whats reflected on the admin interface), and sometimes it doesn't update it on creation either. there's a lot more information inside this file that they could show you like what app requested the upnp but they just don't show it (like Toredo, Skype, identd, etc) its in there, they are just not showing it on the interface (keeping it simple for the user) another issue is the version of upnp they are using to do all this is possibly custom modified over the years (at least we hope!) and may not have all the recent changes/fixes - future versions fixed issues of removing items from this list (just look at the changelog for miniupnpd) they did have a fix for closing the ports on the RFC on the list, and in addition to that... 2018/05/02: option to store remaining time in leasefile which could be useful so you can restart miniunpd or reboot and not lose active upnp ports if they should still be open and devices were never switched off during the reboot, also could help in tracking these and fixing the list with a watcher if a monkey does jump in but this requires netgear to update its daemons and modules, something they don't seem to want to do and nobody ever has given answer to that question as to why?... but rest assured just because its not reporting correctly it is opening/closing the ports as it should because things wouldn't work at all if it wasn't. the kernel has many NAT helpers built into it that do a lot of the work of upnp and bypassing upnp it seems, because I see them being managed through a different way.. certain apps like Skype will show because its old school requesting..or does not have a helper. some apps are only going to request a port once and not again until at least the time limit expires, but if you close an app and reopen it will request again and show on the list (or reboot the xbox so it requests them again) if anything ever jumps out at me i will report of course, and i am no expert in this, just dabbling and like to know how these things are working (and when they don't)
  4. what you are doing with that procedure is by hand what the kernel needs to be doing during startup (it is not a fix), there are some timing issues during boot introducing some monkeys, but at the same time even if you get a stable boot these issues can recur if the right conditions are met (miscommunication between netgears kernel and duma) another guy who throws a wrench in everything is udhcpc daemon who is in charge of getting the WAN IP dhcp lease (public IP lease) from your ISP - each time the lease expires he goes through a whole sequence of events all over again just in case the IP has not been changed by your ISP to ensure that QoS gets reapplied to the correct public IP (same public ip? different public ip?) the scripts he's calling can do some things behind dumas back and may introduce a monkey there too 🙈 since duma needs the data its working with to be accurate for everything to come together -- some people may be just be doing fine for a day or two or three (so how long is your public IP lease? ->Settings, Monitoring, Connection Status --> Lease expires time?) do problems coincide with that timing? things to watch ..
  5. have you tried just disabling QoS and just leave it off prior to/and after the fresh reboot? (just disable QoS, reboot, leave it off) just to see if it works better? turning it on and off when its been up for a while creates some corruption if something is not right gets in there. i know this because of changing some things behind duma os back and forcing/sending dummy DHCP events to device manager while trying to figure out exactly what its doing (which script triggers, etc) after an event to pinpoint the failure.. at one point I was unable to turn off QoS fully since I had removed rules that it was looking for to delete when being turned off, lol. I have yet to factory reset once since getting this router though.. I always have been able to restore it to a very stable working state manually. rebooting the way i said is probably the cleanest reboot you are going to get, but yes whatever is triggering it may pop up again and throw everything out of wack (monkey wrench in the machine) the problem is the constant rebooting everyone is doing without that method creates more problems on each reboot - you never know what you're going to get, especially if some IPs get locked up on a reboot (ones that you've assigned statically) so if the static device requests an IP it can't get its permanently assigned one back so it may get a different one or just decide to up and quit and settle with a 169 non usable ip .. and then as time goes on it just gets more and more out of sync with other settings (qos, port forwards you may have set, etc) i don't think that it is unfixable, it just needs to be fixed. its the illusion that the lan port isn't working, but it is, just the device is not i have faith they will do it. they got some smart guys there, and what they are doing is not an easy task.. i give mad props to the cross.. it's advanced traffic shaping for dummies on the interface, but deep down so much stuff is going on behind the scenes and things need to be in order for it all to come together and one link in the chain fails.. its a cascade of small failures, just a nasty bug that i'm sure they will deal with it. something has to give with netgear
  6. xr500user

    Understanding Hybrid VPN

    it is not a setting you can change with the admin interface. as most know the router is running on linux, so you would have to have at least a pretty good understanding of linux and make changes to certain startup scripts to change the cpu setting on the current firmware during boot. i would not recommend doing this unless you really know what you are doing and ok with the possibility of messing something up badly so i am not going to give the instructions but only these hints that is can be done and you will have to do the research and learning part. that is not the only modification that can be done to boost performance - from reading all the voxel posts available i learned a lot, and after that study in addition you could change some compiler settings when building the base router kernel from the ones netgear uses and it will speed it up even more.. but keep in mind this would have to be done by netgear, and netgear plays it safe and conservative with their kernel it appears. setting the performance mode raises the cpu temp by about 7 degrees -- so it is not a hardware limitation..its a risk they don't want to take - although people are using these settings without any issue (as 3-4c more isn't that much, and its not in the realm of overclocking yet as its forcing the cpu's to use its full spec - all the time, if you start pushing it to 2.0ghz+ now running into danger zone) but as they say .. no risk ... no glory (some are getting 80/85+mbps/sec over the router based VPN on the R7800)
  7. xr500user

    getting DDosed

    for peace of mind (even though you may not be getting DoS attacked, its probably something else) you may need to request a new public IP from your isp. The front line will not have a clue so you will have to escalate it to level 2 or 3 .. it really depends on if they lock your public IP to your cable modem or ONT's mac addr. if they do they are the only ones who can release it, or just return the cable modem and get a new one that has a different mac addr, tell them its broken and you want a new modem. if you are sure they don't lock this, you need to check the public WAN ip lease time on Duma -- in Settings, Monitoring, Connection Status -- take note of Lease Expires time.. when it gets close (within minutes) turn off your XR and turn off your Cable modem.. now wait.. how long you wait after that really depends on if some new customer joins the network and gets your old public IP and even waiting a few minutes is not enough - it may re-request the one it was using and if available, get it back. some recommended turning both off for a whole day. try to make sure your off time is during business hours when new customers are being added to the network or new modems are being activated. You may or may not luck out , its chance gamble .. technically nobody could be added that day and you just get your old public IP back, lol.
  8. yeah, i believe they are aware - but i think not only are there some quirks in device manager (both views) and QoS match tracking which need to be addressed, its netgears base firmware causing some issues to boot the issue is very apparent when using wifi extenders. it seems to work for the most part correctly when the wifi extender is in wifi 'extender' mode. client connects to wifi extender and gets a virtual mac addr, then gets allowed onto the local XR wifi. device manager is good at picking up this virutal mac and merging it with the ip of the actual device (so it knows say iphone X is ab:cc:dd:xx:xx:xx and also cc:xx:dd:xx:xx:xx with IP 192.168.1.x) -- but when extender is in AP mode there are no virtual macs assigned when connected to its wifi, and backhaul is ethernet so its just a pass thru the local LAN (mac addr is true) depending on first connection time and state, this is the issue. if device first connects to an AP, its considered on Local LAN (since pass thru to ethernet) if it jumps off AP wifi and goes to true XR wifi then there's another problem since device manager holds last location (LAN or Wifi) and it will just stay on LAN as online and won't move to wifi side, sometimes marking gets stalled since nothing is triggered until a dhcp event and there are no dhcp events if the client is still in lease time, it won't ask for a new ip. this is one of many scenarios that can start a sh*t storm since device manager can't assume device once on wifi, always on wifi with the same mac addr -- issue that's effecting here is also effecting qos tracking module, if it can't know the device is online and active how can it mark it? it doesn't, so old info may still be in there with prior marks and wrong ip (if it switched) connections get dropped (connection tracking) and it lingers with a reboot and only gets worse after each reboot as the dhcp.leases files gets more and more out of sync along with dumas tracking of them so to say. sometimes if the client leaves the network from wifi, but was thought to be on LAN the ip isn't being cleared by device manager so theres your "Error cannot delete device because its online" - its odd though that table view knows the ip isn't there sometimes (show's N/A) but Tree will still show the IP as online even when offline. now xbox sleeping and waking over and over and over would work in a perfect world but if anything gets some bad info it causes the lost connectivity issue. i'm pretty sure xbox sleep mode (instant on) has no issues on R7800, there is still some legacy things interfering with duma os they have not closed it all down yet. device manager does trigger some events on dhcp renew and other modules also rely on the same information gathering method, so if its wrong, you know problems happen, some may not materialize to state where a user can notice and bitch about, but clearly you see, some are the startup sequence (bootup) causes issues in larger networks where multiple devices have different lease expirations.. and if the lease time is hosed in the XR (for whatever startup reason) it can cause problems because once clients notice a connection is available it will request a renew, or just start thinking hey im ok - im in lease time, and start working as normal. XR kernel has not yet determined its mac addr (and may not know the true ntp time yet so ntp should be set immediately after WAN is up) so it will assign all 00's (incomplete) to that IP it sees data coming from or requested dhcp from, and when the router actually is up and running the device may hit a renew period or request again and oh no that IP is in use, give me a new one, so the router will assign a new IP address to the client, but qos markings are for the old IP - another sh*t storm, and if the IP has a weird lease time of like 1969 or 1970 forget it, its ip will never ever release for use some way the router needs to fully boot and and acquire WAN ip and internet access, duma os needs to fully start (with empty databases and tracking) and then LAN needs to start and then Wifi radio on. at different points of the startup process these things are seen for a split second as active (192.168.1.1) and devices think everything is ok and either request dhcp or mantain what they had before the reboot then interface may get moved to br0 interface but the damage has been done to the files and databases (bad data in there) it may only effect certain devices with just bad luck timing so that's why the more devices the more chance it has to occur.. and if a device actually tries to renew for some it may not get an ip and just give up and set itself to 169.xx.xx.xx - sometimes it works after a reboot so people think its fixed, but its not just had a lucky start up and could occur again yeah it will result is longer boot up times before everything is started, but so be it, just let people know it may be 2,3+ minutes before internet is available on reboot, if you imagine a boot up with multiple APs (which may have 10 clients behind them) all assaulting the dhcp server as soon as it sees some activity from the gateway and certain things are not yet known to the kernel or duma theres other things too that are going on causing issue, its probably best if duma just takes control of the kernel if they just can't get it to work, too many chefs in the kitchen xr700 is just one more complication since the 10G port and the ability to aggregate or use 10G port as uplink or WAN - duma bugs need to addressed, and netgear startup needs to be optimized for all scenarios .. its hard to fix bugs until netgear startup is working optimally, lol. catch .22 .. especially if work arounds were applied for prior bugs that were corrected but now after being corrected cause new bugs, a real hair puller
  9. It's a firmware bug. Clients are jumping onto the router before router dhcp server for local LAN is up and running (this includes wifi clients) I believe it's the sequence of startup for some - with different people experiencing different things depending on ISP, LAN setup, etc. If you have the router up and running with the latest firmware, you can attempt to do a nice reboot but prevent all clients from jumping on.. Turn off the Wifi (to prevent wifi clients from jumping on) It has to be done from a LAN client. Turn off router Wifi. Issue a router reboot. As soon as you issue the reboot, wait a few seconds and disconnect all cables from behind router (WAN, LAN ethernets) Wifi should be off prior. Router reboots .. Wait until it's fully booted Plug in the WAN cable and wait until it's got Internet. Wait a tiny bit after it has Internet, then plug in your local network ethernets, then turn wifi back on This is just one issue.. it can cause weird things like bad dhcpd epoch times (since dhcpd running before actual time known) so IP's get locked to certain macs and they never ever expire, so when the device IP ever changes devices may be associated with multiple IPs in duma databases, and if another device happens to reconnect without renewing its lease (with it's old IP) dhcpd may gave it out to someone else who requests -- so now device manager has two different ip, but thinks it should be for a different mac addr for others - WAN dhcp (udhcpc) is up, but local dhcp (dhcpd) is not (yet), so client requests dhcp and gets an error (since already assigned) so defaults to 169.xx and client is locked there, no ip what needs to be done is run through all startup scripts on the router and make sure you hold back local LAN and wifi until WAN is fully up and ntp time is set then start dhcpd, sleep, then start lan and then start wifi radio and make sure to clear any saved information in device manager databases prior to reboot so it still doesn't fix bugs like sticky IPs based on last connection type for device manager, this is when last connection type was wifi for mac xx:xx:xx:xx:xx:xx and then becomes LAN for same mac. device may stick on either side or be online or offline, but it may make your network stable enough to use for the time being, when qos devices get marked and are not thought to be online, its a problem You can also turn QoS completely off in settings next to Anti-Bufferbloat (disable QoS), do the reboot sequence above and leave it like that. if all is good for a day or two (so any old info expires), then turn QoS back on and see if everything behaves - there is no way to set dhcp lease time in XR500 so its set to 1 day by default, although there is no reason why this can't be changed manually - to really know everything is working nice is to take a look at the dhcp.leases file and make sure it looks good, and not any strange epoch times, but most won't do this unfortunately until its fixed it will continue to some degree over time on those with effected configurations , and i believe it is part of the reason why xbox is having trouble, since it sleeps and wakes and sleeps and wakes, and if at any point something goes wrong in this process and it gets marked for QoS when its online but thought offline it can't maintain connection to its authentication servers because QoS KILLS flows that it doesn't know about in TIME_OUT state and blocks ACK (there's more to it then that, but just an idea), its watching conntrack and theres' a bug there too -- I believe they will fix it, but when -?- don't know -- maybe soon!
  10. xr500user

    Understanding Hybrid VPN

    already notified about the DNS and RTC leak. TCP isn't going to help. It's problematic for all VPN providers. It needs a modification to tunnel VPN DNS into the tun0 device ExpressVPN does push preferred 10.x.x.x DNS server upon connection - Duma ignores - uses preferred or automatic WAN DNS for resolution. speed can be increased by setting the processor to performance mode which netgear doesn't do (ondemand) -- you can do it yourself. ExpressVPN doesn't give tcp configs for download apparently, but just for the curious: mods to config in BOLD (make sure to uncomment with a # where needed): proto tcp-client dev tun #fast-io persist-key persist-tun nobind remote (vpn server you want to use.com) 443 remote-random pull comp-lzo no tls-client verify-x509-name Server name-prefix ns-cert-type server key-direction 1 route-method exe route-delay 2 tun-mtu 1500 #fragment 1300 mssfix 1450 verb 3 cipher AES-256-CBC keysize 256 auth SHA512 sndbuf 524288 rcvbuf 524288 auth-user-pass <<add your cert, etc >> if you get an error on any line in logs, comment it out. if it connects, tcp connection is successful
  11. yes i guess you could say that, but not in routers there is a lot going on and i am by no means a master but getting a better understanding of whats being done with the advanced traffic shaping each time i follow another path putting the puzzle pieces together. there are def. some issue with the local lan <> internet <> lan <> iot when qos is on, its not all devices, i guess it depends on the connection, usually connections that go out to a server and the server comes back in on a different port or to a diff local lan device - device manager issues are only adding to it, that's a different story. something to do with when the connection is marked, and then OUTPUT and INPUT on the firewall side is dropping, maybe misidentify as DoS, dunno, its not blocking everything but blocking one important reply (ack? fin?) from coming back in from the internet to keep the connection alive , could be happening during prerouting - so the connection is just counting down 2 minutes and timing out/closing im surprised your not getting a lot of calls from people with arlo and xr500, because its effected the way arlo works is arlo base -> <local lan> -> router -> <internet> -> aws <ESTABLISHED> and the !reverse ex. say you open arlo app on phone that's on the SAME local lan ... local lan -> router -> <internet> -> aws -> <internet> ->router ->>local lan-> base station and then its screwed on the !reverse all going both directions thru wan - (u have an arlo there? i think you should be able to reproduce it and maybe track down what is being dropped by qos) sometimes connection marked before firewall sees it come back into the base station, it can't connmark packets after the 1st one (when its NEW) ,so arlo may or may not connect or after a lucky connection -- it loses the mark -- the 2 minute countdown starts and instead of renewing you will see "your arlo appears offline." when it is online. All works well when QOS is disabled. so qos is influencing something no doubt something either the input/output is not letting ack back through and connection times out,. it could be effecting authentication servers on iphone , i know it effected port 4433 sonicwall vpns i sent a PM to Fraser the other day with some more things, pls read my other thread i gave some thoughts to look at (more device manager then qos) i will let you know if i find out what it is exactly , can't spend all time looking for it when it can be a simple ! instead of an and, or OR .. it can drive anyone nuts I'll forward it to you..
  12. when i have time i poke around and gain more and more insight each time, but FYI port 4 table view IS the port being used by kernel, end of transmission additional hint VLAN /qos problems on local network - wrong port being mapped to VLAN, actual vs netgear actual additional hint, people reporting 'my iphone isn't connecting','my xxx isn't connecting' -- some wifi devices not connecting because possible race condition from qos <> firewall , conntrack and marking [ASSURED] before firewall sees traffic , firewall TIME_WAIT, NO SYN, error in iptables--- time for flowcharts (dread) rework/fix script works when QOS disabled, because connection is not timing out as quickly, watch the count down till CLOSE i will post when i have time whats going on , with examples, unless you have found it by now?
  13. xr500user

    XR500 hybrid VPN DNS leak test

    i reported this, dec 20th. http://forum.netduma.com/topic/27539-hybrid-vpn-speeds/?do=findComment&comment=204382
  14. xr500user

    Device Manager NOT Working

    i'm sure if you click on the xboxone icon it will show it has an ip address if its connected wifi but not showing theres some bugs in the device manager yes wifi should have its own mac, yes ethernet card should have its own mac but if device does use the same mac for both - device manager isn't working right i posted many scenarios i'm sure they are testing to figure out a fix happens especially with APs with ethernet backhaul (since you connect to the AP wirelessly, but AP is connected to LAN ethernet) if device connects to wifi 1st, it shows, if device then connects to AP (which is wifi, but connected to LAN) device does not shift to LAN or may drop offline and report as offline even tho it has an ip when clicked on if device connects to AP 1st, it shows on LAN, but if device shifts to router wifi, or another AP's wifi, it will stay stuck ONLINE on lan tree, even when offline hell breaks loose with QOS.. they will figure it out. quick way to get it back online, turn xbox off, once ip disappears (wait a little bit), then you'll be able to delete the device, turn xbox on, it will come on wifi side. not a fix, but will work. will go back to funky state again eventually
  15. xr500user

    DHCP OPTION 60 61

    retail. i think it showed up 1 firmware release ago in .32 (i don't use this option)
×