Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


xr500user last won the day on January 6

xr500user had the most liked content!

About xr500user

  • Rank

Recent Profile Visitors

202 profile views
  1. 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..
  2. 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?
  3. 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
  4. 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
  5. xr500user

    DHCP OPTION 60 61

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

    DHCP OPTION 60 61

    hey guy, xr500 has option 61 in settings, internet options --- but not 60 I'm sure they can implement 60 too, web interface only allowing 61 though, can probably do 60 manually
  7. xr500user

    Some bugs ..

    definitely interesting!... I am by no means any expert on this area here, just an observer Maybe it's a duma porting of milestone 1.3 oversight <- This is what I see when poking around - my comments = // So FYI: I have 1-2-3-4 WAN on the back of mine --- //netgear misprint I have 2 switches wired to XR500, one plugged into LAN 1, one into LAN2 (LAN1 being leftmost, furthest from the WAN as per my rear numbering) this is from the OS side XR500: #detcable show //show me what cables are plugged in LAN3 : Plug off LAN2 : Plug off LAN1 : Plug in, 1000M, Full duplex LAN0 : Plug in, 1000M, Full duplex WAN : Plug in, 1000M, Full duplex //matches my misprinted rear numbering - and same as R1? #swconfig dev switch0 show //i removed all the tx rx info Global attributes: enable_vlan: 1 //1=true using 2 vlans, local network is vlan 1, wan is vlan 2 max_frame_size: 1518 dump_arl: MAC: PORTMAP: VID: 0x2 STATUS: 0x0 Port 0: pvid: 2 //wan? on vlan 2 link: port:0 link:up speed:1000baseT full-duplex txflow rxflow Port 1: pvid: 1 //LAN1 port, on vlan 1 link: port:1 link:up speed:1000baseT full-duplex Port 2: pvid: 1 //LAN2 port, on vlan 1 link: port:2 link:up speed:1000baseT full-duplex Port 3: pvid: 1 //LAN3, on vlan 1 link: port:3 link:down Port 4: pvid: 1 //LAN4, on vlan 1 link: port:4 link:down //matches my misprinted rear -- maybe the swconfig needs to be updated to match Netgears portnumbering (oversight?) //XR700 will use next 2 more ports for vlan 1 I assume //and for LEDs -- can they can be mapped? //I found this on OpenWrt //swconfig dev xxxxx port x set led x //dev switch0? //swconfig dev xxxxx set apply //i think they can be reversed, but I do not want to try and brick the router //led controlled by CPU, via gpio<- //not sure if it will stick on this switch though if setting the led Port 5: pvid: 2 //ethwan on vlan 2 to be able to talk to wan from eth switch link: port:5 link:up speed:1000baseT full-duplex txflow rxflow Port 6: pvid: 1 //on vlan 1 not sure what this , guess brwan->br0? the bridge interfaces? link: port:6 link:up speed:1000baseT full-duplex txflow rxflow VLAN 1: vid: 1 ports: 1 2 3 4 6 VLAN 2: vid: 2 ports: 0 //wan 5 //ethwan so either its a mistake from the very beginning by netgear on handling portnumbering from their first Nighthawks and they just always printed the reverse on the back of all their routers: 4-3-2-1-WAN to fix it, rather then really fix it... or duma oversight to update swconfig after porting of milestone 1.3 to xr500 software correction leaves so many places if you forget to fix it in one place it will pop up again, best to have it match the hardware otherwise something just need to keep in mind all the time in your case that's why duma is showing port 4 in table view, its showing what the OS is reporting what port 4 is regardless of whats printed on the back of the case, if you were to do these checks on your router you would see port 3 and 4 are the ones that are link:up not sure if netgear will let duma modify swconfig settings anyone who knows more about switch configurations feel free to jump in
  8. yeah first time seen after you deleted it, always works so you connect ps4 wired or wifi? or both? do you move between wireless n wifi or did you do something like that when it occurred
  9. you managed to trigger the bug somehow whats your network setup like?
  10. xr500user

    Some bugs ..

    hey fraser, do you ever sleep? I'm starting to think your a bot j/k more ... scenario 3: Duma device manager has yet to see this device (brand new) Device connects to local router wifi0,1 and is seen. --> Duma shows client connected on wifi tree Device leaves wifi network (a phone for example - left for work) --> Device drops offline. Device returns later but this time connects to AP first that's ethernet backhauled to LAN --> Device sticks offline, but now has an active IP listed when clicked on. device manager and qos db never updated. Device stuck to offline tree. It's as if the last or current 'Connection Type' was 'Wireless', duma assumes its always Wireless or will return to Wireless and if it rejoins Wired (or the reverse -> joins wired and moves wireless) there's a problem. scenario 4: The reverse may also be true, causing client to stick to Online tree (i have not tested this scenario yet, but i have a feeling its valid) Duma device manager has yet to see this device (brand new) You'd have to be connect to AP wifi first and be shown as online in the LAN tree, then roam/jump to local router wifi0,1 over time. Device will remain stuck to LAN online side and online but listed as connected to local wifi in 'wlan stainfo' ---- then at some point device abruptly leaves the network. Device then never moves from Online LAN side to Offline side, remains stuck online as 'Wired' connection type. IP it claims its currently using when clicked on in device manager is not listed in arp table on router, or may be listed as 0x0 flag with correct mac addr. I believe table view may have IP listed as "N/A" in this case. Table view is doing something a little different then tree view it seems. It appears initially device manager assumes Wireless when it shouldn't. Maybe shouldn't rely on Connection Type as a trigger as it can vary -- last seen connection type is not reliable especially when using multiple APs that are set up with ethernet backhauls, or mixed ethernet backhauls & extenders in extender mode. as said previously, when forcing off a stuck 'truly' offline device that's listed as online on the LAN tree by ping or sending it a few arp packets they drop to offline side instantly. router lists the ip of device at that point in neigh table as 'FAILED' because there is no route to host, it's not online. arp table may or may not have it listed with 0x0 flags, or the device not even listed at all, but will appear for a short time with 00:00 hwaddr and 0x0 flag if the ip isn't in use. it depends on which table is looked at first before attempting to remove the device by sending it some packets. whatever ip you try to send packets to (just make any up 192.168.1.xxx) that's offline - gets a temporary arp entry 0x0 00:00:00 until its removed shortly after automatically and ip neigh show marks as FAILED if not online. neigh table clears shortly after also. arp seems to clear quicker then neigh ..right after device drops to offline tree the logs show device manager db updated and also qos db updated. so it's important this detection and db is correct because over time qos gets hosed for online devices that are thought to be offline qos has rules set to DROP everything first (assumed ddos?) so some packets will drop even though it may have basic internet connectivity but stuck in the offline tree. only solution for this is to disable qos and then device has full internet access when in a 'thought to be offline' state (a qos marked device) and the tree status is still wrong. its super slick what your doing, but it depends on that device database being totally accurate at all times and in all conditions to work flawlessly. I'll send you some more coffee, I'm sure you'll figure it all out.. fraser get some sleep lol
  11. xr500user

    Some bugs ..

    not sure if the "correct" print may actually be the misprint now, lol. most of the images I see online of the router the rear port numbers go left to right [1,2,3,4 WAN] -- but you have [4,3,2,1 WAN] on the back I assume? The front led's are always left to right 1,2,3,4 (some just have only numbers above the leds 1 2 3 4, mine has eth1, eth2, eth3, eth4 printed above the LEDs -left to right-) In your case, the Netgear side thinks the port closest to the WAN(Internet) port is port 1 (this is the error), as it is port 4 according to the router kernel. I think there was some confusion when the issue first appeared that it was a manufacturing printing defect only, but its actually software and printing .. software+rear panel numbering reversed+netgear lighting the wrong led at bootup 4 3 2 1 WAN will light the correct corresponding LED on the front, but it's not the correct port according to the router kernel the lights on the front light up during bootup and they are software lit, the fix probably should of been to isolate the SN's of the routers that had wrong back port printing [4,3,2,1 WAN] and if its in the range to just reverse the front LEDs that are lit at boot -- if they can't do that then an option in the admin panel to reverse them with a checkbox. Then they just had to send you a sticker to stick above the rear ports to renumber them [1,2,3,4 WAN] I'm almost positive the Duma side device manager (table view) is showing the correct kernel port (in your case port 4) and it matches what the OS swconfig switch port id's actually are to the kernel I think [1,2,3,4 WAN] on the rear numbering should be the correct numbering... the lights won't match until the netgear software is fixed to light the right led. that's why i had a feeling netgear side is displaying statistics ports based on led activation and not actual swconfig true port configuration? that has to be fixed.. or it could be that some cable is reversed inside the router (flipped) during assembly causing all of this .. but need to know what is the correct one and if we can manually fix it if it is this It really shouldn't make a difference network wise at if all 4 ports are considered just 1 switch (switch0) in all transactions -- but if by chance netgear or duma side applies any firewall or qos or dpi rules to a specific LAN port, or netgear side keeps statistics on the wrong LAN port it may be an issue if applied to the wrong one, probably on the netgear side more since the OS is reporting the same as duma as to which port is the active port - on another note, it may be causing some issues with device manager.. in regards to sticky devices (a device that is showing an IP still attached to it in Tree view but is on the offline side of the tree) that does not allow you you to delete it (claiming its online): I noticed the same device has no IP attached to it in Table view (correct), but still cannot be deleted .. so it may have something to do with this as some of duma apps may be trying to figure out online/offline/active status are requesting activity (arp,ip neigh show, arpwatching, etc) in a way from sources that aren't being updated in the best manner if netgear side thinks there is no connection to that LAN port (as tree view is unaware the ip has vanished) but table view does know its no longer in use/offline --it shows N/A. -- i know its more and more confusing now... may not be the cause, but it just adds to the mess and possibly f things in the future I think it really needs to be looked at and a fix figured out for all with both printings / led situations and it should show and always use the true kernel port no matter what the printing or led light is on the router, i could care less if its reverse printed or the wrong led on case, just that everything is correct in the OS side
  12. xr500user

    Some bugs ..

    More investigating .. sticky devices scenario 1: if device joins native router wifi radio wifi0,1 (ath0,1) then it is listed correctly in 'wlan stainfo' --> pops device online and shows as online in device manager if said device jumps to an ethernet backhauled AP (jumps to APs wireless radio and AP is backhaul wired to switch->router LAN2) --> duma pushes device to offline tree and shows as offline - stays stuck in offline tree... in actuality, device now active on LAN instead (via AP backhaul) checking: cat /proc/net/arp Device listed in arp table is now with 0x2 Flag -- so now on lan, and active (via AP wired backhaul) When click on device in Device Manager it is reporting correct mac, correct ip, but 'Connection Type' is Wireless and in "Offline" side of tree. Should be moved to LAN/Online in this case arp table flags: Flags 0x2 = online Flags 0x0 = incomplete Not listed, Not on LAN (switch0) 0x0 flagged devices will disappear from arp in a few minutes after device offline if device has 0x0 flag it will hold mac addr for a little bit, devices that are stuck in Online or Offline tree turn into 00:00:00:00:00:00 hwaddr sometimes (now offline, but duma still thinks has an active ip and listed as online) ^eventually removed from arp table any net activity sent towards ip from router root that is stuck online or offline and is truly offline (a ping, or telnet "No route to host", etc) but is actually offline will drop / remove IP from arp (if present), and it will drop from Online to Offline status in Device Manager tree instantly. scenario 2: Device joins AP w/ethernet backhaul wifi first --> duma pops device Online on LAN side of tree Device then shut off, or wifi closed --> duma keeps device listed online, with ip still listed. arp flags are quickly set to 0x0, and eventually removed from arp table (happens rather quickly , seconds) swconfig dev switch0 show --> still holds onto MAC and obsolete PORTMAP info here for a while longer then arp, but then eventually it is removed after a few minutes --> duma still keeps device listed as online (stuck) from now on, with ip still listed as active/connection type 'wired' any net activity sent towards ip from router root that is stuck online (a ping, or telnet "No route to host", etc) the device drops from Online to Offline side of tree instantly. I have not found a way yet to move an offline device that is actually truely online to the correct tree or make duma refresh this device status without turning off its wifi, and deleting it. I hope you guys can re-create this. It's the same if it's directly wired taking the switch out of the picture. Something is not being updated when devices move around, need a double check on all online and offline devices periodically, can't just assume they are online and still online or offline and still offline.. additional: So I have 2 switches (1 AP on switch 1/router lan1, 1 AP on switch2/router lan2) that are plugged into ports labeled 1 and 2 on back of router (this is correct i think) but 3 & 4 LEDs light up on router. Core OS thinks ports listed on back of router are the correct port#s and are active, not the LEDs. but in admin page Settings, Monitoring, Statistics (netgear software side) shows they are listed as LAN3 and LAN4 (same as router LEDs) 3 & 4 LEDs are the right most LEDs on front of my router. double checking... swconfig dev switch0 port 1 show swconfig dev switch0 port 2 show both -->link:up - so back of router numbering and actual port is correct --> 3,4 = link:down (LEDs) duma Device Manager table view shows port 1,2 are connected - also correct I'm not sure but I think all devices will show some discrepancy between netgear settings, monitoring, statistics and duma table port view "misprinted" or not? why does netgear (software side) settings,monitoring,statistics show LAN3 & LAN4 as active? is it only listing link up/down activity based on LED light status and not actual swconfig port status??? <duh> is the switch board installed upsidown internally? can i open the router and flip/reverse a connector? or am i missing something? all pictures of XR500 show LEDs on the front as 1,2,3,4 respectively and 1,2,3,4, WAN on the back as long as the information from statistics means nothing to duma then it doesn't really matter, but if I can fix it I will. wheres that screwdriver .. I'm going in ..lol
  13. it could be a bad cm1000 modem if your 100% sure its rebooting , you see the lights go out and the bootup process start on it? uptime is reset? cm1000 also running linux so if it has a kernel panic it can reboot -- you can try factory resetting the cm1000, make sure latest firmware, and if it has qos on cm100 you can disable it on there too on its admin page if it gets into a situation it doesn't know how to handle yes it can panic and reboot.. but it could have a corrupted file system, bad port, no idea until you troubleshoot it, too many factors
  14. xr500user

    Random Freezes XR500

    this new issue is a little different then just dhcp lease time xr500 has a built in 24 hour lease period i believe - so if a device disconnects it will be given the same ip back when it reconnects (it will even give it back if its still available after the lease time as client may request it as a preferred ip) leases are held in dhcp.leases file in the router with the last time renewed .. this issue is the device disconnects, still in the lease period, but duma still thinks the ip is in use and in an active state, it should not show an ip when you click on a device in device manager if a device is listed in offline, it should just show its mac address -- even if its still in the lease period the router knows when a device is not connected and duma apps query many sources on the router to get this info, just right now its not picking it up sometimes and clients go offline but have a sticky "active" ip still attached -- and sometimes the reverse happens, it's offline , has an active ip, and IS active, but duma holds it in offline state qos rules know what device is active and what they are doing packet wise -- if a device that's marked as offline is sending active packet data weird things can happen with the packets if qos thinks it should be offline .. it could think its a security thing and close connections, or misroute packets -- it doesn't seem to effect the most basic traffic like port 80 web, and some approved default ports, but it does effect higher port ranges, making apps on an effected device not work so well, but once qos is disabled they work in this state as the router itself knows what to do with the packets hope this makes sense
  15. xr500user

    Some bugs ..

    yeah, a bad switch can send out some weird traffic, i have some sx10 which r holding up pretty well so far, but time will tell , i mean i still have business switches that are 15 years old and still working -- no switch should die that soon .. unless power surge or somethin' - does the s8000 have a reset pinhole, i believe the sx10 does .. worth a shot as far as the port numbers yeah, the lights are toggled on by the OS, i saw led files in there .. that's not a big deal to me , can probably fix my light numbering myself, but will be lost with an update .. but what i'm sayin is its in the firmware -- as the port marked on the back (1) is the one shown as connected to LAN 1 on the netgear side in admin panel (check settings, monitoring, statistics) but in the duma side its shown as port 4 (check device manager, Table view) I'm curious since yours has the right markings it should still be effected, but the reverse.. it can only can be noticed if you are not using all 4 lan ports on the router and can see the numbering discrepancy they changed something in the qos/dpi since .32 and its making some mistakes or not updating its table correctly i dont think the numbering would matter since all 4 ports should be just considered one switch (switch0) but if they are specifically addressing individual ports 0x1, 0x2,etc then yes if netgear side thinks the numbering is reversed of course a qos rule will get applied to the wrong lan port# and shit will stir after a while