Re: [Cerowrt-devel] First DNSSEC failure with CeroWRT
It was an interesting find, which btw, silently breaks portions of online banking, as it redirects through the sso gateways. -Aaron Sent from my iPhone > On Apr 19, 2014, at 21:20, Dave Taht wrote: > > you should report it to bank of america and see what happens. > > root@lorna-gw:/etc/config# nslookup www.bankofamerica.com > Server:127.0.0.1 > Address 1: 127.0.0.1 localhost > > Name: www.bankofamerica.com > Address 1: 171.161.207.100 > root@lorna-gw:/etc/config# nslookup sso-fi.bankofamerica.com > Server:127.0.0.1 > Address 1: 127.0.0.1 localhost > > nslookup: can't resolve 'sso-fi.bankofamerica.com': Name or service not known > >> On Sat, Apr 19, 2014 at 12:19 PM, Dave Taht wrote: >> I'm not sure if what you are actually seeing here is a failure or a >> success! It does appear that this is >> indeed a bogus DS. >> >> http://dnssec-debugger.verisignlabs.com/sso-fi.bankofamerica.com >> >>> On Sat, Apr 19, 2014 at 2:43 AM, Aaron Wood wrote: >>> One of the many servers involved with BofA's online banking: >>> >>> Sat Apr 19 09:37:37 2014 daemon.info dnsmasq[29719]: using nameserver >>> 8.8.4.4#53 >>> Sat Apr 19 09:37:37 2014 daemon.info dnsmasq[29719]: using nameserver >>> 8.8.8.8#53 >>> Sat Apr 19 09:37:37 2014 daemon.info dnsmasq[29719]: using local addresses >>> only for domain home.lan >>> Sat Apr 19 09:37:37 2014 daemon.info dnsmasq[29719]: read /etc/hosts - 1 >>> addresses >>> Sat Apr 19 09:37:37 2014 daemon.info dnsmasq-dhcp[29719]: read /etc/ethers - >>> 0 addresses >>> Sat Apr 19 09:37:39 2014 daemon.info dnsmasq[29719]: query[A] >>> saml-bac.onefiserv.com from 172.30.42.99 >>> Sat Apr 19 09:37:39 2014 daemon.info dnsmasq[29719]: forwarded >>> saml-bac.onefiserv.com to 8.8.4.4 >>> Sat Apr 19 09:37:39 2014 daemon.info dnsmasq[29719]: forwarded >>> saml-bac.onefiserv.com to 8.8.8.8 >>> Sat Apr 19 09:37:39 2014 daemon.info dnsmasq[29719]: dnssec-query[DS] >>> saml-bac.onefiserv.com to 8.8.4.4 >>> Sat Apr 19 09:37:41 2014 daemon.info dnsmasq[29719]: reply >>> saml-bac.onefiserv.com is BOGUS DS >>> Sat Apr 19 09:37:41 2014 daemon.info dnsmasq[29719]: validation result is >>> BOGUS >>> Sat Apr 19 09:37:41 2014 daemon.info dnsmasq[29719]: reply >>> saml-bac.onefiserv.com is >>> Sat Apr 19 09:37:41 2014 daemon.info dnsmasq[29719]: reply >>> saml-bac.gslb.onefiserv.com is 64.128.98.58 >>> >>> >>> Sat Apr 19 09:38:04 2014 daemon.info dnsmasq[29719]: query[A] >>> sso-fi.bankofamerica.com from 172.30.42.99 >>> Sat Apr 19 09:38:04 2014 daemon.info dnsmasq[29719]: forwarded >>> sso-fi.bankofamerica.com to 8.8.4.4 >>> Sat Apr 19 09:38:04 2014 daemon.info dnsmasq[29719]: forwarded >>> sso-fi.bankofamerica.com to 8.8.8.8 >>> Sat Apr 19 09:38:04 2014 daemon.info dnsmasq[29719]: dnssec-query[DS] >>> sso-fi.bankofamerica.com to 8.8.8.8 >>> Sat Apr 19 09:38:05 2014 daemon.info dnsmasq[29719]: query[A] >>> sso-fi.bankofamerica.com from 172.30.42.99 >>> Sat Apr 19 09:38:05 2014 daemon.info dnsmasq[29719]: dnssec retry to 8.8.8.8 >>> Sat Apr 19 09:38:06 2014 daemon.info dnsmasq[29719]: reply >>> sso-fi.bankofamerica.com is BOGUS DS >>> Sat Apr 19 09:38:06 2014 daemon.info dnsmasq[29719]: validation result is >>> BOGUS >>> Sat Apr 19 09:38:06 2014 daemon.info dnsmasq[29719]: reply >>> sso-fi.bankofamerica.com is >>> Sat Apr 19 09:38:06 2014 daemon.info dnsmasq[29719]: reply >>> saml-bac.onefiserv.com is 64.128.98.58 >>> >>> ___ >>> Cerowrt-devel mailing list >>> Cerowrt-devel@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/cerowrt-devel >> >> >> >> -- >> Dave Täht >> >> NSFW: >> https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article > > > > -- > Dave Täht > > NSFW: > https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
[Cerowrt-devel] cerowrt-3.10.36-6 released
+ felix's wifi patch for bug #442 added please break wifi. + debloat qlens reduced again to 12 for be and bk wifi queues + heartbleed fix from -3 forward I note that nearly every "secured"-by-openssl network facing daemon has been shown vulnerable to heartbleed. The hole in openvpn bit *me*, in particular. I've updated, rekeyed and re-certified the vpns I have in place, and you should too for any openvpn servers and clients you have too. It was a real PITA for me, and I only had a few boxes on it. For more details, see: http://community.openvpn.net/openvpn/wiki/heartbleed For more details on the daemons potentially affected by heartbleed in cerowrt, openwrt, and others, see the advisory at: http://www.bufferbloat.net/news/50 + resync with openwrt notably there were updates to netifd, and a fix for a strongswan CVE + dnscrypt added as an optional package (thx stephen walker and "mailjoe") + snort added as an optional package +/- full dnssec - upgrade to httping 2.x broke - no sqm autotuning yet - neither snort nor dnscrypt tested If you are not experiencing problems with wifi or with heartbleed there are few reasons to update to this release. I wanted to note to those that use sysupgrade without a clean reflash, in that the /etc/opkg.conf file is not re-written in this case, and still points to the old repository. If you wish to install additional packages after an inplace upgrade, you will have to also update /etc/opkg.conf to point to the right place. -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [aqm] chrome web page benchmarker fixed
On Fri, Apr 18, 2014 at 1:41 PM, Greg White wrote: > On 4/18/14, 1:05 PM, "Dave Taht" wrote: > >>On Fri, Apr 18, 2014 at 11:15 AM, Greg White >>wrote: >>> >>> The choice of RTTs also came from the web traffic captures. I saw >>> RTTmin=16ms, RTTmean=53.8ms, RTTmax=134ms. >> >>Get a median? > > Median value was 62ms. > >> >>My own stats are probably quite skewed lower from being in california, >>and doing some tests from places like isc.org in redwood city, which >>is insanely well >>co-located. > > Mine are probably skewed too. I was told that global median (at the time I > collected this data) was around 100ms. Well, the future is already here, just not evenly distributed. Nearly every sample I'd taken at the same time as from, almost entirely from major cities, came in at under 70ms median. It strikes me that a possibly useful metric would be object size vs RTT, over time. > -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] First DNSSEC failure with CeroWRT
you should report it to bank of america and see what happens. root@lorna-gw:/etc/config# nslookup www.bankofamerica.com Server:127.0.0.1 Address 1: 127.0.0.1 localhost Name: www.bankofamerica.com Address 1: 171.161.207.100 root@lorna-gw:/etc/config# nslookup sso-fi.bankofamerica.com Server:127.0.0.1 Address 1: 127.0.0.1 localhost nslookup: can't resolve 'sso-fi.bankofamerica.com': Name or service not known On Sat, Apr 19, 2014 at 12:19 PM, Dave Taht wrote: > I'm not sure if what you are actually seeing here is a failure or a > success! It does appear that this is > indeed a bogus DS. > > http://dnssec-debugger.verisignlabs.com/sso-fi.bankofamerica.com > > On Sat, Apr 19, 2014 at 2:43 AM, Aaron Wood wrote: >> One of the many servers involved with BofA's online banking: >> >> Sat Apr 19 09:37:37 2014 daemon.info dnsmasq[29719]: using nameserver >> 8.8.4.4#53 >> Sat Apr 19 09:37:37 2014 daemon.info dnsmasq[29719]: using nameserver >> 8.8.8.8#53 >> Sat Apr 19 09:37:37 2014 daemon.info dnsmasq[29719]: using local addresses >> only for domain home.lan >> Sat Apr 19 09:37:37 2014 daemon.info dnsmasq[29719]: read /etc/hosts - 1 >> addresses >> Sat Apr 19 09:37:37 2014 daemon.info dnsmasq-dhcp[29719]: read /etc/ethers - >> 0 addresses >> Sat Apr 19 09:37:39 2014 daemon.info dnsmasq[29719]: query[A] >> saml-bac.onefiserv.com from 172.30.42.99 >> Sat Apr 19 09:37:39 2014 daemon.info dnsmasq[29719]: forwarded >> saml-bac.onefiserv.com to 8.8.4.4 >> Sat Apr 19 09:37:39 2014 daemon.info dnsmasq[29719]: forwarded >> saml-bac.onefiserv.com to 8.8.8.8 >> Sat Apr 19 09:37:39 2014 daemon.info dnsmasq[29719]: dnssec-query[DS] >> saml-bac.onefiserv.com to 8.8.4.4 >> Sat Apr 19 09:37:41 2014 daemon.info dnsmasq[29719]: reply >> saml-bac.onefiserv.com is BOGUS DS >> Sat Apr 19 09:37:41 2014 daemon.info dnsmasq[29719]: validation result is >> BOGUS >> Sat Apr 19 09:37:41 2014 daemon.info dnsmasq[29719]: reply >> saml-bac.onefiserv.com is >> Sat Apr 19 09:37:41 2014 daemon.info dnsmasq[29719]: reply >> saml-bac.gslb.onefiserv.com is 64.128.98.58 >> >> >> Sat Apr 19 09:38:04 2014 daemon.info dnsmasq[29719]: query[A] >> sso-fi.bankofamerica.com from 172.30.42.99 >> Sat Apr 19 09:38:04 2014 daemon.info dnsmasq[29719]: forwarded >> sso-fi.bankofamerica.com to 8.8.4.4 >> Sat Apr 19 09:38:04 2014 daemon.info dnsmasq[29719]: forwarded >> sso-fi.bankofamerica.com to 8.8.8.8 >> Sat Apr 19 09:38:04 2014 daemon.info dnsmasq[29719]: dnssec-query[DS] >> sso-fi.bankofamerica.com to 8.8.8.8 >> Sat Apr 19 09:38:05 2014 daemon.info dnsmasq[29719]: query[A] >> sso-fi.bankofamerica.com from 172.30.42.99 >> Sat Apr 19 09:38:05 2014 daemon.info dnsmasq[29719]: dnssec retry to 8.8.8.8 >> Sat Apr 19 09:38:06 2014 daemon.info dnsmasq[29719]: reply >> sso-fi.bankofamerica.com is BOGUS DS >> Sat Apr 19 09:38:06 2014 daemon.info dnsmasq[29719]: validation result is >> BOGUS >> Sat Apr 19 09:38:06 2014 daemon.info dnsmasq[29719]: reply >> sso-fi.bankofamerica.com is >> Sat Apr 19 09:38:06 2014 daemon.info dnsmasq[29719]: reply >> saml-bac.onefiserv.com is 64.128.98.58 >> >> ___ >> Cerowrt-devel mailing list >> Cerowrt-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel >> > > > > -- > Dave Täht > > NSFW: > https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] First DNSSEC failure with CeroWRT
I'm not sure if what you are actually seeing here is a failure or a success! It does appear that this is indeed a bogus DS. http://dnssec-debugger.verisignlabs.com/sso-fi.bankofamerica.com On Sat, Apr 19, 2014 at 2:43 AM, Aaron Wood wrote: > One of the many servers involved with BofA's online banking: > > Sat Apr 19 09:37:37 2014 daemon.info dnsmasq[29719]: using nameserver > 8.8.4.4#53 > Sat Apr 19 09:37:37 2014 daemon.info dnsmasq[29719]: using nameserver > 8.8.8.8#53 > Sat Apr 19 09:37:37 2014 daemon.info dnsmasq[29719]: using local addresses > only for domain home.lan > Sat Apr 19 09:37:37 2014 daemon.info dnsmasq[29719]: read /etc/hosts - 1 > addresses > Sat Apr 19 09:37:37 2014 daemon.info dnsmasq-dhcp[29719]: read /etc/ethers - > 0 addresses > Sat Apr 19 09:37:39 2014 daemon.info dnsmasq[29719]: query[A] > saml-bac.onefiserv.com from 172.30.42.99 > Sat Apr 19 09:37:39 2014 daemon.info dnsmasq[29719]: forwarded > saml-bac.onefiserv.com to 8.8.4.4 > Sat Apr 19 09:37:39 2014 daemon.info dnsmasq[29719]: forwarded > saml-bac.onefiserv.com to 8.8.8.8 > Sat Apr 19 09:37:39 2014 daemon.info dnsmasq[29719]: dnssec-query[DS] > saml-bac.onefiserv.com to 8.8.4.4 > Sat Apr 19 09:37:41 2014 daemon.info dnsmasq[29719]: reply > saml-bac.onefiserv.com is BOGUS DS > Sat Apr 19 09:37:41 2014 daemon.info dnsmasq[29719]: validation result is > BOGUS > Sat Apr 19 09:37:41 2014 daemon.info dnsmasq[29719]: reply > saml-bac.onefiserv.com is > Sat Apr 19 09:37:41 2014 daemon.info dnsmasq[29719]: reply > saml-bac.gslb.onefiserv.com is 64.128.98.58 > > > Sat Apr 19 09:38:04 2014 daemon.info dnsmasq[29719]: query[A] > sso-fi.bankofamerica.com from 172.30.42.99 > Sat Apr 19 09:38:04 2014 daemon.info dnsmasq[29719]: forwarded > sso-fi.bankofamerica.com to 8.8.4.4 > Sat Apr 19 09:38:04 2014 daemon.info dnsmasq[29719]: forwarded > sso-fi.bankofamerica.com to 8.8.8.8 > Sat Apr 19 09:38:04 2014 daemon.info dnsmasq[29719]: dnssec-query[DS] > sso-fi.bankofamerica.com to 8.8.8.8 > Sat Apr 19 09:38:05 2014 daemon.info dnsmasq[29719]: query[A] > sso-fi.bankofamerica.com from 172.30.42.99 > Sat Apr 19 09:38:05 2014 daemon.info dnsmasq[29719]: dnssec retry to 8.8.8.8 > Sat Apr 19 09:38:06 2014 daemon.info dnsmasq[29719]: reply > sso-fi.bankofamerica.com is BOGUS DS > Sat Apr 19 09:38:06 2014 daemon.info dnsmasq[29719]: validation result is > BOGUS > Sat Apr 19 09:38:06 2014 daemon.info dnsmasq[29719]: reply > sso-fi.bankofamerica.com is > Sat Apr 19 09:38:06 2014 daemon.info dnsmasq[29719]: reply > saml-bac.onefiserv.com is 64.128.98.58 > > ___ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel > -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Having issue upgrading to latest image 3.10.36-4
I just tried a sysupgrade from 3.10.36-1 to 3.10.36-6 and saw this error go by: Appending jffs2 data from /tmp/sysupgrade.tgz to firmware...TRX header not found Error fixing up TRX header The upgrade did indeed succeed, regardless, and kept the files in place. The only "big" update to the conf files I think I've made to the default config since -1 was enabling dnssec-check-unsigned by default in /etc/dnsmasq.conf Going to go beat up wifi for a while today and look into some other dnssec issues. On Sat, Apr 12, 2014 at 11:46 AM, Frits Riep wrote: > I have a Netgear WNDR-3800 and I last updated the firmware about a week ago > successfully using the web interface. I've been trying today to upgrade to > the latest image the same way, but I am not having success and I've tried > the download several times and even with three different browsers but the > result is the same. > > Current Image is 3.10.36-3 > Using this new image for 3.10.36-4: > openwrt-ar71xx-generic-wndr3800-squashfs-sysupgrade.bin > Error Message: > The uploaded image file does not contain a supported format. Make sure that > you choose the generic image format for your platform. > > Please advise if I need to do something different, or have I found a bug. > > thanks > > -Original Message- > From: cerowrt-devel-boun...@lists.bufferbloat.net > [mailto:cerowrt-devel-boun...@lists.bufferbloat.net] On Behalf Of > cerowrt-devel-requ...@lists.bufferbloat.net > Sent: Saturday, April 12, 2014 7:54 AM > To: cerowrt-devel@lists.bufferbloat.net > Subject: Cerowrt-devel Digest, Vol 29, Issue 22 > > Send Cerowrt-devel mailing list submissions to > cerowrt-devel@lists.bufferbloat.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.bufferbloat.net/listinfo/cerowrt-devel > or, via email, send a message with subject or body 'help' to > cerowrt-devel-requ...@lists.bufferbloat.net > > You can reach the person managing the list at > cerowrt-devel-ow...@lists.bufferbloat.net > > When replying, please edit your Subject line so it is more specific than > "Re: Contents of Cerowrt-devel digest..." > > > Today's Topics: > >1. Re: wired article about bleed and bloat and underfunded > critical infrastructure (dpr...@reed.com) >2. DNSSEC failure for *.cloudflare.com via dnsmasq? (Robert Bradley) >3. Re: DNSSEC failure for *.cloudflare.com via dnsmasq? > (Toke H?iland-J?rgensen) >4. Re: DNSSEC failure for *.cloudflare.com via dnsmasq? > (Robert Bradley) >5. Re: cerowrt-3.10.36-4 released (Neil Shepperd) >6. Re: DNSSEC failure for *.cloudflare.com via dnsmasq? > (Robert Bradley) > > > -- > > Message: 1 > Date: Fri, 11 Apr 2014 15:43:19 -0400 (EDT) > From: dpr...@reed.com > To: "Dave Taht" > Cc: "cerowrt-devel@lists.bufferbloat.net" > , bloat > > Subject: Re: [Cerowrt-devel] wired article about bleed and bloat and > underfunded critical infrastructure > Message-ID: <1397245399.392818...@apps.rackspace.com> > Content-Type: text/plain; charset="utf-8" > > > I'm afraid it's not *just* underfunded. I reviewed the details of the code > involved and the fixes, and my conclusion is that even programmers of > security software have not learned how to think about design, testing, etc. > Especially the continuing use of C in a large shared process address space > for writing protocols that are by definition in the "security kernel" > (according to the original definition) of applications on which the public > depends. > > Ever since I was part of the Multics Security Project (which was part of the > effort that produced the Orange Book > http://csrc.nist.gov/publications/history/dod85.pdf) in the 80's, we've > known that security-based code should not be exposed to user code and vice > versa. Yet the SSL libraries are linked in, in userspace, with the > application code. > > Also, upgrades/changes to protocols related to security (which always should > have been in place on every end-to-end connection) should be reviewed *both > at the protocol design level* and also at the *implementation level* because > change creates risk. They should not be adopted blindly without serious > examination and pen-testing, yet this change just was casually thrown in in > a patch release. > > I suspect that even if it were well funded, the folks who deploy the > technology would be slapdash at best. Remember the Y2K issue and the cost of > lazy thinking about dates. (I feel a little superior because in 1968 Multics > standardized on a 72-bit hardware microsecond-resolution hardware clock > because the designers actually thought about long-lived systems (actually > only 56 bits of the original clock worked, but the hardware was not expected > to last until the remaining bits could be added)). > > The open source movement, unfortunately, made a monoculture of the SSL > source cod
Re: [Cerowrt-devel] comcast provisioned rates?
On Sat, Apr 19, 2014 at 11:40 AM, Dave Taht wrote: > On Sat, Apr 19, 2014 at 11:16 AM, wrote: >> Very good. So the idea, rather than Comcast implementing codel or >> something proper in the DOCSIS 3.0 systems they have in the field, is to >> emulate power boost to "impedance match" the add-on router-based codel >> approach to some kind of knowledge of what the DOCSIS CMTS buffering state >> looks like > > http://tools.ietf.org/html/draft-white-aqm-docsis-pie-00 > > is mandated in DOCSIS 3.1 modems. > > The ECO has gone out for DOCSIS 3.0 as well. > > Pie is tightly intertwined with the powerboost capable scheduler. > > The powerboost feature is viewed Oops, hit send too early. The powerboost feature is viewed as a way to reward those that use bandwidth sporadically, such as with website downloads (it's typical duration is more than a website). The cable is a shared medium, and it makes some sense to allow for a bigger burst to someone that isn't otherwise using up that cable as much as someone else. The feature arose in a world of much less bandwidth on the modem by default, and far less users behind a cable modem by default. Yes, in my world, and the upcoming one, I want consistent, predicable, jitter free, bandwidth as it simplifies queue management and makes more possible less hacks on the appliction side to deal with spikes, and so on... but everybody here is living in the future, a bit more than other makers can react. We use more interactive applications, in particular, and some of us have hopes that one day we don't have to co-locate critical servers in the data center anymore. So far as I know powerboost is not enabled on multiple portions of multiple ISPs networks. It wasn't "on" on several places in the west coast when last I checked, anyway. >> And of course nothing can be done about "downstream" bufferbloat in the >> Comcast DOCSIS deployment. > > I have seen promising noises from Arris at least, on the CMTS side, and > had posted some of their thinking from the last meeting of the society > of cable engineers on one of our mailing lists fairly recently, which > induced no comment. > > http://www.ietf.org/mail-archive/web/aqm/current/msg00538.html > > They had come up with a variant of red, called "LRED", and a nifty enhancement > to SFQ, but hadn't got as far as grokking that queue length and packet > scheduling > together were a better answer. > > I would certainly like the overall level of overbuffering in CMTSes to be > reduced which is something the cable providers could do today, and that > certainly bugs me. > >> >> So instead of fixing Comcast's stuff "correctly", we end up with a literal >> "half measure". > > The cable ISP industry as a whole is slave to their equipment makers. > cablelabs only has dominion over the cable modem side. > > What the world needs is better long distance media types not designed > by former telecoms, and designed for packet data. > > If you thought cable was complex and had bad ideas > in it, see gpon, also. Or moca, or various powerline standards. > > What my hope has been has been that the increasingly common > hybrid cable modem/wireless gateways would gain fq_codel support and manage > both the up and downstreams themselves, thus bypassing the > slow to update million dollar head end portion of the industry > entirely. > > I'd like something as powerful and as loved as the revolution V6 box > to appear. > > I'm not holding my breath. > > Apple could do it right. > >> Who does Comcast buy its CMTS gear from, and if it has a Heartbleed bug, >> maybe some benevolent hacker should just fix it for them? > > There are only 3 makers of CMTS gear - cisco, arris, and a third company > from china whose name I forget. > >> >> >> It's now been 2 years since Comcast said they were deploying a fix. Was >> that just them hoping the critics would dissipate their time and effort? > > Competition is needed. I'm rooting for gfiber to provide some. > >> And is Comcast still using its Sandvine DPI gear? > > No idea. I certainly see an aweful lot of packets remarked CS1. > >> >> >> >> I'm afraid that monopolists really don't care. Even friendly-sounding ones. >> Especially when they can use their technical non-deployments to get paid >> more by Netflix. > > Well, grump, I am fair minded. Netflix's business model has always been > to colocate their servers within the ISP itself with things like the > open-connect > appliance. > > http://www.networkworld.com/community/blog/netflix-goes-edge-internet > > It makes a rediculous amount of sense to do so, and is a cost savings > to both ISP and netflix on external bandwidth, but somebody still has to > cover the rack space, hardware, and electricity no matter where located. > > > >> >> >> >> On Saturday, April 19, 2014 1:57pm, "Dave Taht" said: >> >>> The features of the PowerBoost feature are well documented at this >>> point. A proper >>> emulation of them is in the ns2 code. It has been a persistent feature
Re: [Cerowrt-devel] comcast provisioned rates?
On Sat, Apr 19, 2014 at 11:16 AM, wrote: > Very good. So the idea, rather than Comcast implementing codel or > something proper in the DOCSIS 3.0 systems they have in the field, is to > emulate power boost to "impedance match" the add-on router-based codel > approach to some kind of knowledge of what the DOCSIS CMTS buffering state > looks like http://tools.ietf.org/html/draft-white-aqm-docsis-pie-00 is mandated in DOCSIS 3.1 modems. The ECO has gone out for DOCSIS 3.0 as well. Pie is tightly intertwined with the powerboost capable scheduler. The powerboost feature is viewed > And of course nothing can be done about "downstream" bufferbloat in the > Comcast DOCSIS deployment. I have seen promising noises from Arris at least, on the CMTS side, and had posted some of their thinking from the last meeting of the society of cable engineers on one of our mailing lists fairly recently, which induced no comment. http://www.ietf.org/mail-archive/web/aqm/current/msg00538.html They had come up with a variant of red, called "LRED", and a nifty enhancement to SFQ, but hadn't got as far as grokking that queue length and packet scheduling together were a better answer. I would certainly like the overall level of overbuffering in CMTSes to be reduced which is something the cable providers could do today, and that certainly bugs me. > > So instead of fixing Comcast's stuff "correctly", we end up with a literal > "half measure". The cable ISP industry as a whole is slave to their equipment makers. cablelabs only has dominion over the cable modem side. What the world needs is better long distance media types not designed by former telecoms, and designed for packet data. If you thought cable was complex and had bad ideas in it, see gpon, also. Or moca, or various powerline standards. What my hope has been has been that the increasingly common hybrid cable modem/wireless gateways would gain fq_codel support and manage both the up and downstreams themselves, thus bypassing the slow to update million dollar head end portion of the industry entirely. I'd like something as powerful and as loved as the revolution V6 box to appear. I'm not holding my breath. Apple could do it right. > Who does Comcast buy its CMTS gear from, and if it has a Heartbleed bug, > maybe some benevolent hacker should just fix it for them? There are only 3 makers of CMTS gear - cisco, arris, and a third company from china whose name I forget. > > > It's now been 2 years since Comcast said they were deploying a fix. Was > that just them hoping the critics would dissipate their time and effort? Competition is needed. I'm rooting for gfiber to provide some. > And is Comcast still using its Sandvine DPI gear? No idea. I certainly see an aweful lot of packets remarked CS1. > > > > I'm afraid that monopolists really don't care. Even friendly-sounding ones. > Especially when they can use their technical non-deployments to get paid > more by Netflix. Well, grump, I am fair minded. Netflix's business model has always been to colocate their servers within the ISP itself with things like the open-connect appliance. http://www.networkworld.com/community/blog/netflix-goes-edge-internet It makes a rediculous amount of sense to do so, and is a cost savings to both ISP and netflix on external bandwidth, but somebody still has to cover the rack space, hardware, and electricity no matter where located. > > > > On Saturday, April 19, 2014 1:57pm, "Dave Taht" said: > >> The features of the PowerBoost feature are well documented at this >> point. A proper >> emulation of them is in the ns2 code. It has been a persistent feature >> request, to >> add support to some Linux rate shaper to properly emulate PowerBoost, >> but no funding >> ever arrived. >> >> Basically you get 10 extra megabytes above the base rate at whatever >> rate the line >> can sustain before it settles back to the base rate. >> >> You can also see that as presently implemented, at least on a short >> RTT path, the feature >> does not prevent bufferbloat. >> >> http://snapon.lab.bufferbloat.net/~cero2/jimreisert/results.html >> >> I'd like a faster, less cpu intense rate shaper than sch_htb in >> general, and powerboost emulation would be nice. >> >> >> On Sat, Apr 19, 2014 at 9:38 AM, Aaron Wood wrote: >> > Based on these results: >> > >> > http://snapon.lab.bufferbloat.net/~cero2/jimreisert/results.html >> > >> > And talking off-list with Jim, I think that the "PowerBoost" is above >> > the >> > quoted rate, as the 24/4 service hits >36Mbps TCP data rate. I'm >> definitely >> > sad that using SQM in the router instead of the modem loses features >> > like >> > that. But I'll just be happy to have upload over 1Mbps again. >> > >> > I do know that the FCC was cracking down on advertised vs. actual rates, >> > and >> > started a "measuring broadband in America" project: >> > >> > http://www.fcc.gov/measuring-broadband-america >> > >> > -Aaron >> > >> > >> > On Sat, Apr
Re: [Cerowrt-devel] comcast provisioned rates?
Very good. So the idea, rather than Comcast implementing codel or something proper in the DOCSIS 3.0 systems they have in the field, is to emulate power boost to "impedance match" the add-on router-based codel approach to some kind of knowledge of what the DOCSIS CMTS buffering state looks like And of course nothing can be done about "downstream" bufferbloat in the Comcast DOCSIS deployment. So instead of fixing Comcast's stuff "correctly", we end up with a literal "half measure". Who does Comcast buy its CMTS gear from, and if it has a Heartbleed bug, maybe some benevolent hacker should just fix it for them? It's now been 2 years since Comcast said they were deploying a fix. Was that just them hoping the critics would dissipate their time and effort? And is Comcast still using its Sandvine DPI gear? I'm afraid that monopolists really don't care. Even friendly-sounding ones. Especially when they can use their technical non-deployments to get paid more by Netflix. On Saturday, April 19, 2014 1:57pm, "Dave Taht" said: > The features of the PowerBoost feature are well documented at this > point. A proper > emulation of them is in the ns2 code. It has been a persistent feature > request, to > add support to some Linux rate shaper to properly emulate PowerBoost, > but no funding > ever arrived. > > Basically you get 10 extra megabytes above the base rate at whatever > rate the line > can sustain before it settles back to the base rate. > > You can also see that as presently implemented, at least on a short > RTT path, the feature > does not prevent bufferbloat. > > http://snapon.lab.bufferbloat.net/~cero2/jimreisert/results.html > > I'd like a faster, less cpu intense rate shaper than sch_htb in > general, and powerboost emulation would be nice. > > > On Sat, Apr 19, 2014 at 9:38 AM, Aaron Wood wrote: > > Based on these results: > > > > http://snapon.lab.bufferbloat.net/~cero2/jimreisert/results.html > > > > And talking off-list with Jim, I think that the "PowerBoost" is above the > > quoted rate, as the 24/4 service hits >36Mbps TCP data rate. I'm > definitely > > sad that using SQM in the router instead of the modem loses features like > > that. But I'll just be happy to have upload over 1Mbps again. > > > > I do know that the FCC was cracking down on advertised vs. actual rates, and > > started a "measuring broadband in America" project: > > > > http://www.fcc.gov/measuring-broadband-america > > > > -Aaron > > > > > > On Sat, Apr 19, 2014 at 6:21 PM, wrote: > >> > >> As a non-Comcast-customer, I am curious too. I had thought their > "boost" > >> feature allowed temporary rates *larger* than the quoted "up to" rates. > >> (but I remember the old TV-diagonal games and disk capacity games, where > any > >> way to get a larger number was used in the advertising, since the FTC > didn't > >> have a definition that could be applied). > >> > >> > >> > >> I wonder if some enterprising lawyer might bring the necessary consumer > >> fraud class-action before the FTC to get clear definitions of the > numbers? > >> It's probably too much to ask for Comcast to go on the record with a > precise > >> definition. > >> > >> > >> > >> > >> > >> On Saturday, April 19, 2014 8:55am, "Aaron Wood" > said: > >> > >> I'm setting up new service in the US, and I'm currently assuming that > all > >> of Comcast's rates are "boosted" rates, not the "provisioned" rates. > >> So if they quote 50/10Mbps, I assume that's not what will need to be set > >> in SQM with CeroWRT. > >> Does anyone have good info on the "provisioned" rates that go with each > of > >> the Comcast tiers? > >> Basically, I'm trying to get to an apples-to-apples comparison with > >> Sonic.net DSL (I'll be close enough to the CO to run in Annex M "upload > >> priority" mode and get ~18/2 service). > >> Thanks, > >> Aaron > > > > > > > > ___ > > Cerowrt-devel mailing list > > Cerowrt-devel@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/cerowrt-devel > > > > > > -- > Dave Täht > > NSFW: > https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article >___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [Bug #442] < vs <= in two comparisons
On Sat, Apr 19, 2014 at 4:22 AM, Felix Fietkau wrote:
> On 2014-04-19 05:26, Dave Taht wrote:
>> Could part of it be as simple as not checking for '<=' but only < in
>> txq_max_pending below?
> I don't see how that would make any meaningful difference in practice.
Didn't think it would, still thought <= was more correct.
> By the way, did you test my patch?
It is in the as yet untested 3.10.36-6 build, along with resetting qlen
down to 12 again to try to trigger the bug sooner.
http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.10.36-6/
>
>> in ath_tx_start:
>>
>> ath_txq_lock(sc, txq);
>> if (txq == sc->tx.txq_map[q] &&
>> ++txq->pending_frames > sc->tx.txq_max_pending[q] &&
>> !txq->stopped) {
>> ieee80211_stop_queue(sc->hw, q);
>> txq->stopped = true;
>> }
>>
>> in ath_txq_skb_done:
>>
>> if (txq->stopped &&
>> txq->pending_frames < sc->tx.txq_max_pending[q]) {
>> ieee80211_wake_queue(sc->hw, q);
>> txq->stopped = false;
>> }
>>
>>
>
--
Dave Täht
NSFW:
https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] open ports on WAN
On Sat, Apr 19, 2014 at 9:36 AM, Chuck Anderson wrote:
> I was curious to see what services were open on the WAN to the CeroWrt
> router itself. It looks like the following services are open and not
> firewalled via iptables directly:
>
> 21 telnet
> 22 ssh
> 23 ftp
> 873 rsync
> 12865 netserver
>
> The only thing blocking access is the xinetd configuration:
>
> defaults
> {
> per_source = 16
> only_from = 192.168.0.0/16 172.16.0.0/12
> instances = 18
> max_load = 16
> }
> Is this a good idea, relying only on this default config to block
> access to those services? Or should the iptables firewall default to
> blocking everything and only poke holes where they are needed rather
> than how it is now--only blocking a list of ports which doesn't
> include the above ports?
telnet and ftp are actually sensors that detect probe attempts and
block off attempts to access any other services from the offending
IP.
I like the sensor capability, and wish it could trigger adding firewall
rules as well.
Rsync has no conf file by default, and ssh and netserver are limited by
default to the common internal IP addresses.
You can tighten these down further if you like.
> ___
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
--
Dave Täht
NSFW:
https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] comcast provisioned rates?
The features of the PowerBoost feature are well documented at this point. A proper emulation of them is in the ns2 code. It has been a persistent feature request, to add support to some Linux rate shaper to properly emulate PowerBoost, but no funding ever arrived. Basically you get 10 extra megabytes above the base rate at whatever rate the line can sustain before it settles back to the base rate. You can also see that as presently implemented, at least on a short RTT path, the feature does not prevent bufferbloat. http://snapon.lab.bufferbloat.net/~cero2/jimreisert/results.html I'd like a faster, less cpu intense rate shaper than sch_htb in general, and powerboost emulation would be nice. On Sat, Apr 19, 2014 at 9:38 AM, Aaron Wood wrote: > Based on these results: > > http://snapon.lab.bufferbloat.net/~cero2/jimreisert/results.html > > And talking off-list with Jim, I think that the "PowerBoost" is above the > quoted rate, as the 24/4 service hits >36Mbps TCP data rate. I'm definitely > sad that using SQM in the router instead of the modem loses features like > that. But I'll just be happy to have upload over 1Mbps again. > > I do know that the FCC was cracking down on advertised vs. actual rates, and > started a "measuring broadband in America" project: > > http://www.fcc.gov/measuring-broadband-america > > -Aaron > > > On Sat, Apr 19, 2014 at 6:21 PM, wrote: >> >> As a non-Comcast-customer, I am curious too. I had thought their "boost" >> feature allowed temporary rates *larger* than the quoted "up to" rates. >> (but I remember the old TV-diagonal games and disk capacity games, where any >> way to get a larger number was used in the advertising, since the FTC didn't >> have a definition that could be applied). >> >> >> >> I wonder if some enterprising lawyer might bring the necessary consumer >> fraud class-action before the FTC to get clear definitions of the numbers? >> It's probably too much to ask for Comcast to go on the record with a precise >> definition. >> >> >> >> >> >> On Saturday, April 19, 2014 8:55am, "Aaron Wood" said: >> >> I'm setting up new service in the US, and I'm currently assuming that all >> of Comcast's rates are "boosted" rates, not the "provisioned" rates. >> So if they quote 50/10Mbps, I assume that's not what will need to be set >> in SQM with CeroWRT. >> Does anyone have good info on the "provisioned" rates that go with each of >> the Comcast tiers? >> Basically, I'm trying to get to an apples-to-apples comparison with >> Sonic.net DSL (I'll be close enough to the CO to run in Annex M "upload >> priority" mode and get ~18/2 service). >> Thanks, >> Aaron > > > > ___ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel > -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] comcast provisioned rates?
Based on these results: http://snapon.lab.bufferbloat.net/~cero2/jimreisert/results.html And talking off-list with Jim, I think that the "PowerBoost" is above the quoted rate, as the 24/4 service hits >36Mbps TCP data rate. I'm definitely sad that using SQM in the router instead of the modem loses features like that. But I'll just be happy to have upload over 1Mbps again. I do know that the FCC was cracking down on advertised vs. actual rates, and started a "measuring broadband in America" project: http://www.fcc.gov/measuring-broadband-america -Aaron On Sat, Apr 19, 2014 at 6:21 PM, wrote: > As a non-Comcast-customer, I am curious too. I had thought their "boost" > feature allowed temporary rates *larger* than the quoted "up to" rates. > (but I remember the old TV-diagonal games and disk capacity games, where > any way to get a larger number was used in the advertising, since the FTC > didn't have a definition that could be applied). > > > > I wonder if some enterprising lawyer might bring the necessary consumer > fraud class-action before the FTC to get clear definitions of the numbers? > It's probably too much to ask for Comcast to go on the record with a > precise definition. > > > > > > On Saturday, April 19, 2014 8:55am, "Aaron Wood" said: > > I'm setting up new service in the US, and I'm currently assuming that > all of Comcast's rates are "boosted" rates, not the "provisioned" rates. > So if they quote 50/10Mbps, I assume that's not what will need to be set > in SQM with CeroWRT. > Does anyone have good info on the "provisioned" rates that go with each of > the Comcast tiers? > Basically, I'm trying to get to an apples-to-apples comparison with > Sonic.net DSL (I'll be close enough to the CO to run in Annex M "upload > priority" mode and get ~18/2 service). > Thanks, > Aaron > ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
[Cerowrt-devel] open ports on WAN
I was curious to see what services were open on the WAN to the CeroWrt
router itself. It looks like the following services are open and not
firewalled via iptables directly:
21 telnet
22 ssh
23 ftp
873 rsync
12865 netserver
The only thing blocking access is the xinetd configuration:
defaults
{
per_source = 16
only_from = 192.168.0.0/16 172.16.0.0/12
instances = 18
max_load = 16
}
Is this a good idea, relying only on this default config to block
access to those services? Or should the iptables firewall default to
blocking everything and only poke holes where they are needed rather
than how it is now--only blocking a list of ports which doesn't
include the above ports?
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] comcast provisioned rates?
As a non-Comcast-customer, I am curious too. I had thought their "boost" feature allowed temporary rates *larger* than the quoted "up to" rates. (but I remember the old TV-diagonal games and disk capacity games, where any way to get a larger number was used in the advertising, since the FTC didn't have a definition that could be applied). I wonder if some enterprising lawyer might bring the necessary consumer fraud class-action before the FTC to get clear definitions of the numbers? It's probably too much to ask for Comcast to go on the record with a precise definition. On Saturday, April 19, 2014 8:55am, "Aaron Wood" said: I'm setting up new service in the US, and I'm currently assuming that all of Comcast's rates are "boosted" rates, not the "provisioned" rates. So if they quote 50/10Mbps, I assume that's not what will need to be set in SQM with CeroWRT. Does anyone have good info on the "provisioned" rates that go with each of the Comcast tiers? Basically, I'm trying to get to an apples-to-apples comparison with Sonic.net DSL (I'll be close enough to the CO to run in Annex M "upload priority" mode and get ~18/2 service). Thanks, Aaron___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
[Cerowrt-devel] comcast provisioned rates?
I'm setting up new service in the US, and I'm currently assuming that all of Comcast's rates are "boosted" rates, not the "provisioned" rates. So if they quote 50/10Mbps, I assume that's not what will need to be set in SQM with CeroWRT. Does anyone have good info on the "provisioned" rates that go with each of the Comcast tiers? Basically, I'm trying to get to an apples-to-apples comparison with Sonic.net DSL (I'll be close enough to the CO to run in Annex M "upload priority" mode and get ~18/2 service). Thanks, Aaron ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [Bug #442] < vs <= in two comparisons
On 2014-04-19 05:26, Dave Taht wrote:
> Could part of it be as simple as not checking for '<=' but only < in
> txq_max_pending below?
I don't see how that would make any meaningful difference in practice.
By the way, did you test my patch?
> in ath_tx_start:
>
> ath_txq_lock(sc, txq);
> if (txq == sc->tx.txq_map[q] &&
> ++txq->pending_frames > sc->tx.txq_max_pending[q] &&
> !txq->stopped) {
> ieee80211_stop_queue(sc->hw, q);
> txq->stopped = true;
> }
>
> in ath_txq_skb_done:
>
> if (txq->stopped &&
> txq->pending_frames < sc->tx.txq_max_pending[q]) {
> ieee80211_wake_queue(sc->hw, q);
> txq->stopped = false;
> }
>
>
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
[Cerowrt-devel] First DNSSEC failure with CeroWRT
One of the many servers involved with BofA's online banking: Sat Apr 19 09:37:37 2014 daemon.info dnsmasq[29719]: using nameserver 8.8.4.4#53 Sat Apr 19 09:37:37 2014 daemon.info dnsmasq[29719]: using nameserver 8.8.8.8#53 Sat Apr 19 09:37:37 2014 daemon.info dnsmasq[29719]: using local addresses only for domain home.lan Sat Apr 19 09:37:37 2014 daemon.info dnsmasq[29719]: read /etc/hosts - 1 addresses Sat Apr 19 09:37:37 2014 daemon.info dnsmasq-dhcp[29719]: read /etc/ethers - 0 addresses Sat Apr 19 09:37:39 2014 daemon.info dnsmasq[29719]: query[A] saml-bac.onefiserv.com from 172.30.42.99 Sat Apr 19 09:37:39 2014 daemon.info dnsmasq[29719]: forwarded saml-bac.onefiserv.com to 8.8.4.4 Sat Apr 19 09:37:39 2014 daemon.info dnsmasq[29719]: forwarded saml-bac.onefiserv.com to 8.8.8.8 Sat Apr 19 09:37:39 2014 daemon.info dnsmasq[29719]: dnssec-query[DS] saml-bac.onefiserv.com to 8.8.4.4 Sat Apr 19 09:37:41 2014 daemon.info dnsmasq[29719]: reply saml-bac.onefiserv.com is BOGUS DS Sat Apr 19 09:37:41 2014 daemon.info dnsmasq[29719]: validation result is BOGUS Sat Apr 19 09:37:41 2014 daemon.info dnsmasq[29719]: reply saml-bac.onefiserv.com is Sat Apr 19 09:37:41 2014 daemon.info dnsmasq[29719]: reply saml-bac.gslb.onefiserv.com is 64.128.98.58 Sat Apr 19 09:38:04 2014 daemon.info dnsmasq[29719]: query[A] sso-fi.bankofamerica.com from 172.30.42.99 Sat Apr 19 09:38:04 2014 daemon.info dnsmasq[29719]: forwarded sso-fi.bankofamerica.com to 8.8.4.4 Sat Apr 19 09:38:04 2014 daemon.info dnsmasq[29719]: forwarded sso-fi.bankofamerica.com to 8.8.8.8 Sat Apr 19 09:38:04 2014 daemon.info dnsmasq[29719]: dnssec-query[DS] sso-fi.bankofamerica.com to 8.8.8.8 Sat Apr 19 09:38:05 2014 daemon.info dnsmasq[29719]: query[A] sso-fi.bankofamerica.com from 172.30.42.99 Sat Apr 19 09:38:05 2014 daemon.info dnsmasq[29719]: dnssec retry to 8.8.8.8 Sat Apr 19 09:38:06 2014 daemon.info dnsmasq[29719]: reply sso-fi.bankofamerica.com is BOGUS DS Sat Apr 19 09:38:06 2014 daemon.info dnsmasq[29719]: validation result is BOGUS Sat Apr 19 09:38:06 2014 daemon.info dnsmasq[29719]: reply sso-fi.bankofamerica.com is Sat Apr 19 09:38:06 2014 daemon.info dnsmasq[29719]: reply saml-bac.onefiserv.com is 64.128.98.58 ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
