Re: [Cerowrt-devel] Lost access to Web GUI
On Mon, Feb 16, 2015 at 4:41 AM, Rich Brown wrote: > I figured it out. > > The default "blockconfig2" rule in the firewall prevents access to the > configuration ports of CeroWrt from any host in a *guest* network. Switching > to a non-guest network (from CEROwrt-guest5 to CEROwrt5) allows me to log in > with ease. > > D'oh! Yes. I also note that by default stuff connected via the meshy wifi interfaces are also blocked from access to the web gui. And my reasoning for using port 81 rather than 80, is that it is easy to accidentally open up port 80 to the universe via ipv6, and preferred to avoid that. In fact, I really do wish that the world of embedded devices had chosen a non-default port for their configuration web gui in light of their potential exposure to the universe via ipv6, or those that did were more careful about only accepting local connections by default. That said, even that is not enough. There are going to be an awful lot of printers exposed the ipv6 internet on port 631 (ipp) for example, and hacks have already deployed that can get your printer to emit spam, at the very least. I note that I do, in my own, trusted environments, I do allow the meshy interfaces full reign to the gui and secure network (it makes them a lot more useful), but ya know, I am generally careful enough to actually change admin passwords and the like, everywhere, on everything. > Rich > > > On Feb 9, 2015, at 7:54 AM, Rich Brown wrote: > >> I cannot currently get to the web GUI on CeroWrt. When I browse to >> gw.home.lan:80, I see the short "Welcome to CeroWrt" page. Clicking the link >> gives a page that says "Redirecting" with >> http://gw.home.lan/bgi-bin/redir.sh in the URL bar. Shortly thereafter the >> page times out. telnet gw.home.lan 81 fails - I get "Trying 172.30.42.1..." >> but no connection. >> >> The router is otherwise working just fine. >> >> I first noticed this yesterday, and I didn't have time to write it up. I >> believe this has happened before. In the past, I believe that I waited a few >> days and it came back. (only 80% sure of this - I may just have rebooted.) >> >> I'm using CeroWrt 3.10.50-1. Uptime is 46+ days. I can ssh in, so I can get >> diagnostic info including the cerostats.sh output (below). >> >> Any thoughts? What else should I check/try? Thanks. >> >> Rich >> >> # I have not changed any of the lighttpd .conf files >> root@cerowrt:/usr/lib/CeroWrtScripts# ps | grep http >> 1334 www-data 3956 S/usr/sbin/lighttpd -D -f /etc/lighttpd/cerowrt.conf >> 3389 root 4840 S/usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf >> 19089 root 1388 Sgrep http >> >> # somebody's listening on ports 80 & 81 >> root@cerowrt:/usr/lib/CeroWrtScripts# netstat -ant >> Active Internet connections (servers and established) >> Proto Recv-Q Send-Q Local Address Foreign Address State >> tcp0 0 0.0.0.0:139 0.0.0.0:* LISTEN >> tcp0 0 0.0.0.0:80 0.0.0.0:* LISTEN >> tcp0 0 0.0.0.0:81 0.0.0.0:* LISTEN >> tcp0 0 0.0.0.0:53 0.0.0.0:* LISTEN >> tcp0 0 0.0.0.0:21 0.0.0.0:* LISTEN >> tcp0 0 0.0.0.0:23 0.0.0.0:* LISTEN >> tcp0 0 0.0.0.0:445 0.0.0.0:* LISTEN >> tcp0 0 71.173.64.49:23 200.153.251.230:50013 TIME_WAIT >> tcp0208 172.30.42.1:22 172.30.42.184:51213 >> ESTABLISHED >> tcp0 0 :::12865:::*LISTEN >> tcp0 0 :::873 :::*LISTEN >> tcp0 0 :::139 :::*LISTEN >> tcp0 0 :::80 :::*LISTEN >> tcp0 0 :::81 :::*LISTEN >> tcp0 0 :::53 :::*LISTEN >> tcp0 0 :::22 :::*LISTEN >> tcp0 0 :::8123 :::*LISTEN >> tcp0 0 :::445 :::*LISTEN >> >> root@cerowrt:/usr/lib/CeroWrtScripts# cat /tmp/cerostats_output.txt >> [date] >> Mon Feb 9 07:30:10 EST 2015 >> >> >> [uname -a] >> Linux cerowrt.home.lan 3.10.50 #2 Mon Jul 28 21:04:41 PDT 2014 mips GNU/Linux >> >> >> [uptime] >> 07:30:10 up 46 days, 14:48, load average: 0.16, 0.04, 0.05 >> >> >> [ifconfig] >> 6in4-henet Link encap:IPv6-in-IPv4 >> inet6 addr: 2001:470:1f06:64::2/64 Scope:Global >> inet6 addr: fe80::47ad:4031/128 Scope:Link >> UP POINTOPOINT RUNNING NOARP MTU:1424 Metric:1 >> RX packets:417210 errors:0 dropped:0 overruns:0 frame:0 >> TX packets:426630 errors:0 dropped:0 overruns:0 carrier:0 >> collisions:
Re: [Cerowrt-devel] Lost access to Web GUI
Dave - I understand the rationale, but the real issue here is with the printers, etc. Their security model is completely inappropriate - even WITHIN a home network... depending on peripheral protection doesn't work anywhere very well. It's so easy to break into someone's home net... either by exploiting a hole, or by social engineering. And it is worse in any enterprise network. At my last two large company employers, the amount of attack traffic within the Intranet, behind the firewall, was measured, and it is FAR worse than in the public Internet (and Sony showed us how risky that is). IPP should be default secure, with authenticated users only able to use it. There's a way to make this simpler - establish an authentication server in the home, and require every device to have a relationship with the authentication server, so the category of "authorized devices" is easy to set up. NAT is not a proper security solution. It's features can be useful to reduce the frequency of some attacks, and maybe DoS. Maybe CeroWRT should have a good authentication server in it, turned on by default, and with a well-designed user experience to make adding a device easy, and provide that device with the authorized credentials. We've known how to do this since Kerberos was designed - it was designed to work exactly this way. Instead this crappy "border protection" model has become the only mental model of security. Companies have locked desks, locked offices, badges, etc. And they don't place their entire security bet on the receptionist at the front door. On Wednesday, February 25, 2015 12:21pm, "Dave Taht" said: > On Mon, Feb 16, 2015 at 4:41 AM, Rich Brown wrote: >> I figured it out. >> >> The default "blockconfig2" rule in the firewall prevents access to the >> configuration ports of CeroWrt from any host in a *guest* network. Switching >> to a >> non-guest network (from CEROwrt-guest5 to CEROwrt5) allows me to log in with >> ease. >> >> D'oh! > > Yes. I also note that by default stuff connected via the meshy wifi > interfaces are also blocked from access to the web gui. And my > reasoning for using port 81 rather than 80, is that it is easy to > accidentally open up port 80 to the universe via ipv6, and preferred > to avoid that. In fact, I really do wish that the world of embedded > devices had chosen a non-default port for their configuration web gui > in light of their potential exposure to the universe via ipv6, or > those that did were more careful about only accepting local > connections by default. > > That said, even that is not enough. > > There are going to be an awful lot of printers exposed the ipv6 > internet on port 631 (ipp) for example, and hacks have already > deployed that can get your printer to emit spam, at the very least. > > I note that I do, in my own, trusted environments, I do allow the > meshy interfaces full reign to the gui and secure network (it makes > them a lot more useful), but ya know, I am generally careful enough to > actually change admin passwords and the like, everywhere, on > everything. > >> Rich >> >> >> On Feb 9, 2015, at 7:54 AM, Rich Brown wrote: >> >>> I cannot currently get to the web GUI on CeroWrt. When I browse to >>> gw.home.lan:80, I see the short "Welcome to CeroWrt" page. Clicking the link >>> gives a page that says "Redirecting" with >>> http://gw.home.lan/bgi-bin/redir.sh in >>> the URL bar. Shortly thereafter the page times out. telnet gw.home.lan 81 >>> fails >>> - I get "Trying 172.30.42.1..." but no connection. >>> >>> The router is otherwise working just fine. >>> >>> I first noticed this yesterday, and I didn't have time to write it up. I >>> believe >>> this has happened before. In the past, I believe that I waited a few days >>> and it >>> came back. (only 80% sure of this - I may just have rebooted.) >>> >>> I'm using CeroWrt 3.10.50-1. Uptime is 46+ days. I can ssh in, so I can get >>> diagnostic info including the cerostats.sh output (below). >>> >>> Any thoughts? What else should I check/try? Thanks. >>> >>> Rich >>> >>> # I have not changed any of the lighttpd .conf files >>> root@cerowrt:/usr/lib/CeroWrtScripts# ps | grep http >>> 1334 www-data 3956 S/usr/sbin/lighttpd -D -f /etc/lighttpd/cerowrt.conf >>> 3389 root 4840 S/usr/sbin/lighttpd -D -f >>> /etc/lighttpd/lighttpd.conf >>> 19089 root 1388 Sgrep http >>> >>> # somebody's listening on ports 80 & 81 >>> root@cerowrt:/usr/lib/CeroWrtScripts# netstat -ant >>> Active Internet connections (servers and established) >>> Proto Recv-Q Send-Q Local Address Foreign Address State >>> tcp0 0 0.0.0.0:139 0.0.0.0:* LISTEN >>> tcp0 0 0.0.0.0:80 0.0.0.0:* LISTEN >>> tcp0 0 0.0.0.0:81 0.0.0.0:* LISTEN >>> tcp0 0 0.0.0.0:53 0.0.0.0:* LISTEN >>> tcp0 0 0.0.0.
Re: [Cerowrt-devel] Lost access to Web GUI
dpr...@reed.com writes: > Maybe CeroWRT should have a good authentication server in it, turned > on by default, and with a well-designed user experience to make adding > a device easy, and provide that device with the authorized > credentials. Does such a thing exist that is supported by the stuff you'd want to apply this to? -Toke ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Lost access to Web GUI
While I understand your frustration (my day job is security), people will take "it works" over "it's secure, but fiddly to setup" any day. This is why so many people still run unencrypted wireless. Frankly, it's hard enough to get things to talk to network printers that adding a dependency on a central authentication server is asking a LOT. Now, if cerowrt could run an AD compatible server, it would be useful for some people, but for many, their laptops are tied to a company domain, getting them to work well in a home domain as well is going to be messy. David Lang On Wed, 25 Feb 2015, dpr...@reed.com wrote: Dave - I understand the rationale, but the real issue here is with the printers, etc. Their security model is completely inappropriate - even WITHIN a home network... depending on peripheral protection doesn't work anywhere very well. It's so easy to break into someone's home net... either by exploiting a hole, or by social engineering. And it is worse in any enterprise network. At my last two large company employers, the amount of attack traffic within the Intranet, behind the firewall, was measured, and it is FAR worse than in the public Internet (and Sony showed us how risky that is). IPP should be default secure, with authenticated users only able to use it. There's a way to make this simpler - establish an authentication server in the home, and require every device to have a relationship with the authentication server, so the category of "authorized devices" is easy to set up. NAT is not a proper security solution. It's features can be useful to reduce the frequency of some attacks, and maybe DoS. Maybe CeroWRT should have a good authentication server in it, turned on by default, and with a well-designed user experience to make adding a device easy, and provide that device with the authorized credentials. We've known how to do this since Kerberos was designed - it was designed to work exactly this way. Instead this crappy "border protection" model has become the only mental model of security. Companies have locked desks, locked offices, badges, etc. And they don't place their entire security bet on the receptionist at the front door. On Wednesday, February 25, 2015 12:21pm, "Dave Taht" said: On Mon, Feb 16, 2015 at 4:41 AM, Rich Brown wrote: I figured it out. The default "blockconfig2" rule in the firewall prevents access to the configuration ports of CeroWrt from any host in a *guest* network. Switching to a non-guest network (from CEROwrt-guest5 to CEROwrt5) allows me to log in with ease. D'oh! Yes. I also note that by default stuff connected via the meshy wifi interfaces are also blocked from access to the web gui. And my reasoning for using port 81 rather than 80, is that it is easy to accidentally open up port 80 to the universe via ipv6, and preferred to avoid that. In fact, I really do wish that the world of embedded devices had chosen a non-default port for their configuration web gui in light of their potential exposure to the universe via ipv6, or those that did were more careful about only accepting local connections by default. That said, even that is not enough. There are going to be an awful lot of printers exposed the ipv6 internet on port 631 (ipp) for example, and hacks have already deployed that can get your printer to emit spam, at the very least. I note that I do, in my own, trusted environments, I do allow the meshy interfaces full reign to the gui and secure network (it makes them a lot more useful), but ya know, I am generally careful enough to actually change admin passwords and the like, everywhere, on everything. Rich On Feb 9, 2015, at 7:54 AM, Rich Brown wrote: I cannot currently get to the web GUI on CeroWrt. When I browse to gw.home.lan:80, I see the short "Welcome to CeroWrt" page. Clicking the link gives a page that says "Redirecting" with http://gw.home.lan/bgi-bin/redir.sh in the URL bar. Shortly thereafter the page times out. telnet gw.home.lan 81 fails - I get "Trying 172.30.42.1..." but no connection. The router is otherwise working just fine. I first noticed this yesterday, and I didn't have time to write it up. I believe this has happened before. In the past, I believe that I waited a few days and it came back. (only 80% sure of this - I may just have rebooted.) I'm using CeroWrt 3.10.50-1. Uptime is 46+ days. I can ssh in, so I can get diagnostic info including the cerostats.sh output (below). Any thoughts? What else should I check/try? Thanks. Rich # I have not changed any of the lighttpd .conf files root@cerowrt:/usr/lib/CeroWrtScripts# ps | grep http 1334 www-data 3956 S/usr/sbin/lighttpd -D -f /etc/lighttpd/cerowrt.conf 3389 root 4840 S/usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf 19089 root 1388 Sgrep http # somebody's listening on ports 80 & 81 root@cerowrt:/usr/lib/CeroWrtScripts# netstat -ant Active Internet connections (servers and established) Prot
Re: [Cerowrt-devel] Lost access to Web GUI
I shipped kerberos in cerowrt 3.7. Nobody cared. the package broke, and I never got around to fixing. it. It was the last e-e security system that worked - and it works well on both ipv4 (when nat is not present) and ipv6. isc uses it quite sanely internally. If microsoft hadn't bowdlerized it in Active Directory and instead remained interoperable, It would be a better world. On Wed, Feb 25, 2015 at 11:31 AM, David Lang wrote: > While I understand your frustration (my day job is security), people will > take "it works" over "it's secure, but fiddly to setup" any day. This is why > so many people still run unencrypted wireless. > > Frankly, it's hard enough to get things to talk to network printers that > adding a dependency on a central authentication server is asking a LOT. > > Now, if cerowrt could run an AD compatible server, it would be useful for > some people, but for many, their laptops are tied to a company domain, > getting them to work well in a home domain as well is going to be messy. > > David Lang > > On Wed, 25 Feb 2015, dpr...@reed.com wrote: > >> Dave - I understand the rationale, but the real issue here is with the >> printers, etc. >> >> Their security model is completely inappropriate - even WITHIN a home >> network... depending on peripheral protection doesn't work anywhere very >> well. It's so easy to break into someone's home net... either by exploiting >> a hole, or by social engineering. And it is worse in any enterprise >> network. >> >> At my last two large company employers, the amount of attack traffic >> within the Intranet, behind the firewall, was measured, and it is FAR worse >> than in the public Internet (and Sony showed us how risky that is). >> >> IPP should be default secure, with authenticated users only able to use >> it. There's a way to make this simpler - establish an authentication server >> in the home, and require every device to have a relationship with the >> authentication server, so the category of "authorized devices" is easy to >> set up. >> >> NAT is not a proper security solution. It's features can be useful to >> reduce the frequency of some attacks, and maybe DoS. >> >> Maybe CeroWRT should have a good authentication server in it, turned on by >> default, and with a well-designed user experience to make adding a device >> easy, and provide that device with the authorized credentials. >> >> We've known how to do this since Kerberos was designed - it was designed >> to work exactly this way. >> >> Instead this crappy "border protection" model has become the only mental >> model of security. >> >> Companies have locked desks, locked offices, badges, etc. And they don't >> place their entire security bet on the receptionist at the front door. >> >> >> >> On Wednesday, February 25, 2015 12:21pm, "Dave Taht" >> said: >> >>> On Mon, Feb 16, 2015 at 4:41 AM, Rich Brown >>> wrote: I figured it out. The default "blockconfig2" rule in the firewall prevents access to the configuration ports of CeroWrt from any host in a *guest* network. Switching to a non-guest network (from CEROwrt-guest5 to CEROwrt5) allows me to log in with ease. D'oh! >>> >>> >>> Yes. I also note that by default stuff connected via the meshy wifi >>> interfaces are also blocked from access to the web gui. And my >>> reasoning for using port 81 rather than 80, is that it is easy to >>> accidentally open up port 80 to the universe via ipv6, and preferred >>> to avoid that. In fact, I really do wish that the world of embedded >>> devices had chosen a non-default port for their configuration web gui >>> in light of their potential exposure to the universe via ipv6, or >>> those that did were more careful about only accepting local >>> connections by default. >>> >>> That said, even that is not enough. >>> >>> There are going to be an awful lot of printers exposed the ipv6 >>> internet on port 631 (ipp) for example, and hacks have already >>> deployed that can get your printer to emit spam, at the very least. >>> >>> I note that I do, in my own, trusted environments, I do allow the >>> meshy interfaces full reign to the gui and secure network (it makes >>> them a lot more useful), but ya know, I am generally careful enough to >>> actually change admin passwords and the like, everywhere, on >>> everything. >>> Rich On Feb 9, 2015, at 7:54 AM, Rich Brown wrote: > I cannot currently get to the web GUI on CeroWrt. When I browse to > gw.home.lan:80, I see the short "Welcome to CeroWrt" page. Clicking the > link > gives a page that says "Redirecting" with > http://gw.home.lan/bgi-bin/redir.sh in > the URL bar. Shortly thereafter the page times out. telnet gw.home.lan > 81 fails > - I get "Trying 172.30.42.1..." but no connection. > > The router is otherwise working just fine. > > I first noticed this yesterday, and I didn't have time to write it up. > I believe
Re: [Cerowrt-devel] Lost access to Web GUI
On Wed, 25 Feb 2015, Dave Taht wrote: I shipped kerberos in cerowrt 3.7. Nobody cared. the package broke, and I never got around to fixing. it. It was the last e-e security system that worked - and it works well on both ipv4 (when nat is not present) and ipv6. isc uses it quite sanely internally. If microsoft hadn't bowdlerized it in Active Directory and instead remained interoperable, It would be a better world. No disagreement there, but microsoft did, and as a result what would be needed is AD, not just kerberos. There's also the problem that kerberos requires that the time be set correctly, something that is very commonly not the case on home devices (especially things like printers) David Lang On Wed, Feb 25, 2015 at 11:31 AM, David Lang wrote: While I understand your frustration (my day job is security), people will take "it works" over "it's secure, but fiddly to setup" any day. This is why so many people still run unencrypted wireless. Frankly, it's hard enough to get things to talk to network printers that adding a dependency on a central authentication server is asking a LOT. Now, if cerowrt could run an AD compatible server, it would be useful for some people, but for many, their laptops are tied to a company domain, getting them to work well in a home domain as well is going to be messy. David Lang On Wed, 25 Feb 2015, dpr...@reed.com wrote: Dave - I understand the rationale, but the real issue here is with the printers, etc. Their security model is completely inappropriate - even WITHIN a home network... depending on peripheral protection doesn't work anywhere very well. It's so easy to break into someone's home net... either by exploiting a hole, or by social engineering. And it is worse in any enterprise network. At my last two large company employers, the amount of attack traffic within the Intranet, behind the firewall, was measured, and it is FAR worse than in the public Internet (and Sony showed us how risky that is). IPP should be default secure, with authenticated users only able to use it. There's a way to make this simpler - establish an authentication server in the home, and require every device to have a relationship with the authentication server, so the category of "authorized devices" is easy to set up. NAT is not a proper security solution. It's features can be useful to reduce the frequency of some attacks, and maybe DoS. Maybe CeroWRT should have a good authentication server in it, turned on by default, and with a well-designed user experience to make adding a device easy, and provide that device with the authorized credentials. We've known how to do this since Kerberos was designed - it was designed to work exactly this way. Instead this crappy "border protection" model has become the only mental model of security. Companies have locked desks, locked offices, badges, etc. And they don't place their entire security bet on the receptionist at the front door. On Wednesday, February 25, 2015 12:21pm, "Dave Taht" said: On Mon, Feb 16, 2015 at 4:41 AM, Rich Brown wrote: I figured it out. The default "blockconfig2" rule in the firewall prevents access to the configuration ports of CeroWrt from any host in a *guest* network. Switching to a non-guest network (from CEROwrt-guest5 to CEROwrt5) allows me to log in with ease. D'oh! Yes. I also note that by default stuff connected via the meshy wifi interfaces are also blocked from access to the web gui. And my reasoning for using port 81 rather than 80, is that it is easy to accidentally open up port 80 to the universe via ipv6, and preferred to avoid that. In fact, I really do wish that the world of embedded devices had chosen a non-default port for their configuration web gui in light of their potential exposure to the universe via ipv6, or those that did were more careful about only accepting local connections by default. That said, even that is not enough. There are going to be an awful lot of printers exposed the ipv6 internet on port 631 (ipp) for example, and hacks have already deployed that can get your printer to emit spam, at the very least. I note that I do, in my own, trusted environments, I do allow the meshy interfaces full reign to the gui and secure network (it makes them a lot more useful), but ya know, I am generally careful enough to actually change admin passwords and the like, everywhere, on everything. Rich On Feb 9, 2015, at 7:54 AM, Rich Brown wrote: I cannot currently get to the web GUI on CeroWrt. When I browse to gw.home.lan:80, I see the short "Welcome to CeroWrt" page. Clicking the link gives a page that says "Redirecting" with http://gw.home.lan/bgi-bin/redir.sh in the URL bar. Shortly thereafter the page times out. telnet gw.home.lan 81 fails - I get "Trying 172.30.42.1..." but no connection. The router is otherwise working just fine. I first noticed this yesterday, and I didn't have time to write it up. I believe this has happened before. In th
Re: [Cerowrt-devel] Lost access to Web GUI
David Lang writes: > No disagreement there, but microsoft did, and as a result what would > be needed is AD, not just kerberos. https://www.samba.org/samba/news/releases/4.0.0.html ? :) > There's also the problem that kerberos requires that the time be set > correctly, something that is very commonly not the case on home > devices (especially things like printers) Do common network-enabled printers actually support kerberos (or AD)? Even consumer-targeted devices? -Toke ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Lost access to Web GUI
On Wed, 25 Feb 2015, Toke Høiland-Jørgensen wrote: David Lang writes: No disagreement there, but microsoft did, and as a result what would be needed is AD, not just kerberos. https://www.samba.org/samba/news/releases/4.0.0.html ? :) Yep, that's what I was thinking of. But I don't know if it achieves that other requirement (having an easy to use user interaction to manage) There's also the problem that kerberos requires that the time be set correctly, something that is very commonly not the case on home devices (especially things like printers) Do common network-enabled printers actually support kerberos (or AD)? Even consumer-targeted devices? I'd be surprised if they did. Even if they did, do people really want to go to the hassle of connecting their device to a domain when they are at a friend's house and need to print one document? David Lang___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [Bloat] Two d-link products tested for bloat...
> Here's a comparison plot of box totals: http://www.candelatech.com/downloads/rtt_fair4be-comparison-box-plot.png That's a real mess. All of them utterly fail to get download bandwidth anywhere near the upload (am I right in assuming it should ideally be about equal?), and the only ones with even halfway acceptable latency are the ones with least throughput in either direction. - Jonathan Morton ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [Bloat] Two d-link products tested for bloat...
On Wed, Feb 25, 2015 at 4:18 PM, Jonathan Morton wrote: >> Here's a comparison plot of box totals: > http://www.candelatech.com/downloads/rtt_fair4be-comparison-box-plot.png > > That's a real mess. All of them utterly fail to get download bandwidth > anywhere near the upload (am I right in assuming it should ideally be about > equal?), and the only ones with even halfway acceptable latency are the ones > with least throughput in either direction. And I suspect that this was a test at the highest possible MCS rates and txpower. Isaac? > > - Jonathan Morton -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [Bloat] Two d-link products tested for bloat...
I did some rtt_fair4be tests on different APs per Dave's request. The test setup was a LANforge 802.11ac box with a wired port connected to the AP LAN port and with 4 emulated wireless stations that were connected to the AP wireless over the air. I ran the test on each of the following APs with firmware versions: netgear3700v2 - 1.0.0.12 netgear6300 - v1.0.2.70_1.0.50 netgear7000 - dd-wrt-23884M dlink-dgl5500 - 1.11b03 linksys1900ac - 1.1.7.160582 asus-rt-ac66r - 3.0.0.4.374_5517 Here's a comparison plot of box totals: http://www.candelatech.com/downloads/rtt_fair4be-comparison-box-plot.png Here's a tarball of all the test results: http://candelatech.com/downloads/rtt_fair4be-ap-tests.tgz I'm still refining the test setup, so I'll be re-running these as well as trying out other APs. Isaac On 02/19/2015 06:04 PM, Dave Taht wrote: I ordered a d-link DGL-5500 from amazon this week. It arrived today. This is their almost top of the line 802.11ac router. Their streamboost QoS feature - the first thing you see on their configuration page - LOVELY gui, actually! - was entirely broken in the uplink direction. Admittedly that was the first generation firmware. I know how hard it is to get that right. So I tried to update it. My attempt to update the firmware for it from their website, bricked it. And it appears the only way to update it, or to update it to openwrt, is via a gui, not tftp. ok so... In an orgy of giving companies that don´t deserve my money, money, I also got the DIR-860L. It was the "A1" model, which of course, has no support in openwrt, and there is no way to figure out if an online retailer is selling the entirely different B model or not. Their version of the QoS system was entirely broken in *both directions*. While I was mildly happy that it used weighted fair queuing by default, bandwidth limitation failed to work *at all*, except, that it did classify CS1 traffic, as *higher* priority than best effort. So in both cases, no matter what you did, even if you tried to do the right thing... you had bufferbloat induced on the next hop (if, I was trying to actually test this on a cablemodem or dsl link) I would really to flush this crap from the marketplace, and the only way left, I think, is to stop being a nice guy. My problem is, that I really am a nice guy, and the only way I could possibly do that is put on a persona, do a blog, call it something like the angry engineer, or something like that. But I am pretty sure that venom I would have to summon on a daily basis would be bad for my blood pressure. Maybe we could all get together on it, and only raise our collective BP by a point or three each? The Avenging Engineers? the relevant netperf-wrapper data is in each of these dirs: http://snapon.lab.bufferbloat.net/~d/DIR-860L/dir-860L-bandwidth-broke-in-both-directions.png http://snapon.lab.bufferbloat.net/~d/dgl-5500/totalfailure-to-control-the-upload.png On Wed, Feb 18, 2015 at 1:28 AM, Sebastian Moeller wrote: Hi Felix, hi List, On Jan 25, 2015, at 12:09 , Felix Fietkau wrote: Here's another candidate: http://us.dlink.com/products/connect/wireless-ac1200-dual-band-gigabit-cloud-router-dir-860l/ CPU: MT7621 (dual-core MIPS, 880 MHz, 4 virtual CPUs) The device has preliminary OpenWrt support already. In my tests, handles ~820 Mbit/s NAT without any special acceleration features (with fq_codel, no shaping). Haven't done any tests with shaping yet. Wifi (MT7612E) is still buggy with my mt76 driver, but I'll fix that in March when I get back from vacation. - Felix I am currently searching for a replacement for my wndr3700v2 as it is running out of steam on my temporary 100/40 Mbps link. This thing looks quite decent, but I notice between https://wikidevi.com/wiki/D-Link_DIR-860L_rev_A1 and https://wikidevi.com/wiki/D-Link_DIR-860L_rev_B1 that d-link reused the sam name for quite different hardware implementations, and only the more recent B1 revision will work for us. (Is it just me or do you also find this tendency to not even add the revision to the official name a bit annoying?) So, does anybody here now how to order a specific revision in Germany? Or is the only way to wait a bit and hope the A1 revision clears the retail channel so only B1’s are left? I notice that from looking at the internal photos for both devices posted on the FCC site that the old A1 Broadcom revision has its USB port "above" the ethernet ports while the B1 Mediatek revision has the USB port between DC in and below the ethernet ports. Am I correct in assuming that deployed hardware needs to match the FCC design exactly (that is, in case of revision a new FCC submission with new photos is required)? Best Regards Sebastian -- Isaac Konikoff Candela Technologies konik...@candelatech.com Office: 360-380-1618 Mobile: 360-389-2453 ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net
Re: [Cerowrt-devel] [Bloat] Two d-link products tested for bloat...
On 02/25/2015 04:23 PM, Dave Taht wrote: On Wed, Feb 25, 2015 at 4:18 PM, Jonathan Morton wrote: Here's a comparison plot of box totals: http://www.candelatech.com/downloads/rtt_fair4be-comparison-box-plot.png That's a real mess. All of them utterly fail to get download bandwidth anywhere near the upload (am I right in assuming it should ideally be about equal?), and the only ones with even halfway acceptable latency are the ones with least throughput in either direction. And I suspect that this was a test at the highest possible MCS rates and txpower. Isaac? Yes, highest MCS for each AP and fw defaulted tx power. I can experiment with attenuation and lower MCS rates as well. - Jonathan Morton ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [Bloat] Two d-link products tested for bloat...
On Wed, Feb 25, 2015 at 8:22 PM, Isaac Konikoff wrote: > > > On 02/25/2015 04:23 PM, Dave Taht wrote: >> >> On Wed, Feb 25, 2015 at 4:18 PM, Jonathan Morton >> wrote: Here's a comparison plot of box totals: >>> >>> http://www.candelatech.com/downloads/rtt_fair4be-comparison-box-plot.png >>> >>> That's a real mess. All of them utterly fail to get download bandwidth >>> anywhere near the upload (am I right in assuming it should ideally be >>> about >>> equal?), and the only ones with even halfway acceptable latency are the >>> ones >>> with least throughput in either direction. >> >> >> And I suspect that this was a test at the highest possible MCS rates >> and txpower. Isaac? > > > Yes, highest MCS for each AP and fw defaulted tx power. I can experiment > with attenuation and lower MCS rates as well. Be prepared to be horrified in disbelief at your results at the lower rates... and post them anyway. I note that rtt_fair4be is a pretty stressful, artificial benchmark, and to truly stress things out requires more than one tcp flow per station in each direction, or attempting to also exercise the 802.11e queues. Or interference. Or multicast. I do believe, that once these enormous latencies are clobbered via various techniques in make-wifi-fast that it is possible to get bandwidth per station over tcp to degrade nearly linearly, and achieve close to the theoretical rate of the air, and for latencies to remain (on this 4 station test) typically in the 4-14ms range at all but the lowest MCS rates. IMHO an AP that one day does well on these tests will also do much better on a variety of others. :) btw, I show a detailed graph of TCP's actual behavior under circumstances like these at nearly every talk, with data taken on the actual conference wifi. It never occurred to me once, to show the bar chart! (out of the 14+ plots available). It might be helpful on your next test run to also do the simplest tests to a single station over each AP for a reference (tcp_upload, tcp_download, and tcp_bidirectional). >> >>> >>> - Jonathan Morton >> >> >> >> > -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
