We only drop legacy packets so it's okay



  • A colleague told me he can't access "some sites" anymore. This only happens when he's connected to a certain wifi access point. We run an ICMP traceroute. It works. Then we run a TCP traceroute on port 80. It works. Then we run a traceroute on port 443, that works too. So why are some sites not working?

    Gee, if we do the port 80 trace over IPv4, there is no response. Let's try port 443 on IPv4? Works.

    OFFICIAL NETGEAR TCP PRECIATION CHART
    
      Port   | IPv4 IPv6
      -------+----------
      21     |  ✔    ✔
      70     |  ✔    ✔
      80     | :wtf:   ✔
      443    |  ✔    ✔
    

    How can somebody even consider building something like that? How did we end up with a product that can't reliably fulfill its main purpose of just delivering pacekts? Yes I'm angry. Angry at this access point for messing with packets. Angry at Netgear for making such access points. Angry at the world for allowing Netgear to exist.



  • This post is deleted!


  • Reportedly the problems started when "we'd briefly plugged something in the WAN port."


  • BINNED

    @fbmac seems to have dropped some packets too



  • @gleemonk Netgear exists solely to marginally reduce the cost of home-sized Cisco routers.



  • @gleemonk said in We only drop legacy packets so it's okay:

    How can somebody even consider building something like that? How did we end up with a product that can't reliably fulfill its main purpose of just delivering pacekts?

    Well, TCP on port 80 is unsecured HTTP, and THAT'S THA EVILZ! So akshually we are protecting you in case you have the dumbz.
    We just haven't gotten around to blocking it on IPV6, too, because seriously, nobody uses that anyway, amirite?


  • I survived the hour long Uno hand

    @gleemonk
    I mean, that sounds more like the result of shitty testing, or the result of a "security" setting that suddenly became on by default (or was enabled by a user who didn't know exactly what it did), rather than malicious blocking by NetGear.

    Some routers do a kind of captive-portal thing (think hotel HotSpots) for first run, maybe the AP just reset to factory defaults and needs the first run thing done again, change the password and Bob's your uncle?



  • @ScienceCat said in We only drop legacy packets so it's okay:

    Well, TCP on port 80 is unsecured HTTP, and THAT'S THA EVILZ!

    My colleague certainly would've found out earlier if he weren't using the EFF extension HTTPS Everywhere.

    @izzion said in We only drop legacy packets so it's okay:

    Some routers do a kind of captive-portal thing (think hotel HotSpots) for first run, maybe the AP just reset to factory defaults and needs the first run thing done again, change the password and Bob's your uncle?

    Nice theory. It would still be pretty shitty though to reset the device password and such without also resetting the SSID and the WPA password. I just hope it didn't turn on its DHCP server too without telling anybody.

    In any case the portal page is not shown. The packets just disappear. Of course in your scenario the router would be in a totally different subnet from everybody else, messing up its options when it comes to responding to the hijacked HTTP connection attempts.


  • I survived the hour long Uno hand

    @gleemonk
    Depending on how it was originally configured, I could maaaaaaybe see something where plugging in the WAN side suddenly caused the Hotspot functionality to trigger (especially if the WAN side got a valid DHCP lease and suddenly could phone home via the Internet) -- the "first run" flag was never cleared, but the router defaults to a more open mode until it successfully phones home, at which point the Hotspot behavior occurs until the first run is cleared.

    Seems pretty far fetched to me, but most people on this forum have seen software that did more :wtf: things.



  • Well that all sounds like a reasona

    phone home

    WHAAAAAAGRGLBA


Log in to reply