Re: [Cerowrt-devel] security guidelines for home routers
On Tue, 27 Nov 2018 12:03:35 +0100, Mikael Abrahamsson said: > I'd really like to see a wider audience weigh in on the pro:s and con:s of > this approach. Do parents really want to come home to their 12 year old > who might have opened up their residential gateway and installed something > the 12 year old downloaded from the Internet? Perhaps yes, perhaps no. That's a parenting problem not easily solved via technology. In particular, there's the issue that often, the 12 year old is more clever than the parent - or the person who designed the parental controls on the device. On Tue, 27 Nov 2018 13:17:57 +0200, Jonathan Morton said: > Currently, the easiest way to build a machine that's *truly* secure is to > take something like a 6502 (which is still being manufactured by WDC) and > associated 74AHC-series logic chips, SRAMs and EEPROMs, a 4-layer PCBs, all of > which are built on crude enough technology to be physically examined for > backdoor devices in an airport-grade X-ray machine if necessary. Then write > the necessary software in assembly, which can be translated to machine code > (or > at least verified) by hand if you're truly paranoid, and toggle it in byte by >byte on the front panel. > Good luck getting a web browser running on one of those, though. Couldn't find a browser, but somebody cooked up an ethernet based webserver for a 6502.. https://developers.slashdot.org/story/03/08/16/1226253/a-tcpip-stack-and-web-server-in-basic pgpe8V7vnvZwu.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Wicked OT: 240.0.0.0/4 netblock
On Fri, 19 Oct 2018 11:53:21 -0700, Dave Taht said: > An attempt to make "E" useful died a decade ago: > https://tools.ietf.org/html/draft-fuller-240space-02 > > Still, it would be a better world with 268m more routable ips in it, > wouldn't it? Not really. That ship sailed long ago - class E space is effectively useless until a large percentage of systems are upgraded to support it. And if you're going to be upgrading all the CPE and ISP hardware/software *anyhow*, you may as well enable and use IPv6 and get a lot more than 268M routable addresses for the effort. And its presence in bogon lists will make it quite the whack-a-mole challenge. Those of us who have been around for a while can remember all the fun when 8/8 and 12/8 were no longer bogons. And the net was a lot smaller then, with a lot fewer moles that needed whacking. pgpStZK7f5Ybq.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] wifi trick with comcast
On Tue, 09 Oct 2018 13:17:53 -0700, Dave Taht said: > https://msol.io/blog/tech/how-i-doubled-my-internet-speed-with-openwrt/ Wonder what happens if/when the neighbor notices... ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] linus vs wireguard
On Thu, 02 Aug 2018 11:56:59 -0700, Dave Taht said: > I just spent a few hugely frustrating days trying to code in and being > frightened by, ebpf. While I hates it thus far, a mini-language of > some sort suitable for hardware offloads seems useful. That's just screaming for an ebpf to FPGA compiler. :) pgphJXF2Z2cuj.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] openwrt 18.06.0 released
On Wed, 01 Aug 2018 11:04:14 -0700, Dave Taht said: > If you haven't retired your cerowrt yet, now's the time. > > http://lists.infradead.org/pipermail/openwrt-devel/2018-August/013449.html > > cake still required some manual configuration at the rc2. Ah. I wonder if that's related to why I thought I had SQM and Cake in the .config, but it keeps telling me that congestion control is 'cubic' when it actually boots. (Running a git pull from Saturday) pgp8GtQdeWFOi.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] So how far behind is the embedded router world, still?
On Thu, 26 Jul 2018 09:13:47 -0400, "dpr...@deepplum.com" said: > Maybe one could even start with a Linux kernel, but only that. Init() would > be entirely different, and only a subset would be used. The ABI would be > extended for simpler user space coding of device, network, ... logic that > directly operates the hardware and presents simple queue based (rings?) IPC. Congrats. You just re-invented the UIO (Userspace I/O) driver. pgp3VTapsW8zk.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] So how far behind is the embedded router world, still?
On Wed, 25 Jul 2018 11:50:31 -0700, Dave Taht said: > I recently took apart verizon FIOS's current firmware for one of their > more popular routers. It's still running 2.6.21, which shipped in > june, 2007. Overgeneralizing from this one data point, I am wondering > if the trendline for new routing products tracking current software > has got worse or better? I have to admit I bought a Linksys WRT1200AC and it didn't stay on factory firmware long enough for me to check, it got Lede installed right over the top before it got swapped in for the old router Friends don't let friends run factory firmware... :) pgpPxYku37kK8.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Invisibility of bufferbloat and its remedies
On Mon, 18 Jun 2018 18:46:18 -0700, Dave Taht said: > One of cake's "minor" features is the *perfect* defeat of the htb > based shaper in cable modems. If you know the set-rate on the modem, > you just set it to the same thing and get vastly superior performance to > docsis 3.1, pie, or the sqm-scripts. Do we have a good cookbook on how to determine the set-rate? ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] spacebee
On Tue, 13 Mar 2018 09:52:53 -0700, Dave Taht said: > Spacebee - Having a payload 1/4th the size of a cubesat *work* and be > useable! is a major advance. And is 1/4th the space junk. Worrying > about something smaller than baseball hitting anything strikes me as > control freakery at the FCC. For the purposes of this example, we'll assume that a large bolt sized piece of space debris is about the same size as a 50 caliber sniper round. That leaves the rifle going about 4,000 feet per second. A piece of space debris can hit at anywhere from almost zero to twice the orbital speed, depending on relative orbit angles (the 2009 Iridium incident they hit at almost exactly 90 degrees, so 17000 mph times sqrt(2)). For that configuration, they collided at around 25,000 feet per second. And kinetic energy is 0.5 * m v ^2. So that bolt ends up whacking you with about 40 times the force of a 50 caliber round. That's gonna mess up your day unless you have some serious armor - which is the last thing anything in orbit has due to the cost of launching per pound (even the ISS is only armored enough to stop something up to 1.5cm or so). If you want to use a baseball as the example, find the video of Randy Johnson pegging a stray pigeon. And his baseball was going around 100mph. Apply "one half em vee squared" and we get 17000^2 / 100^2 - or a baseball in orbit has 28,900 times the kinetic energy. The Iridium constellation of 66 satellites already has to deal with some 400 incidents *per week* where known space junk passes within 5km. And in most cases, the exact orbitals for at least one of the bodies aren't exactly known - in the 2009 incident, they had been predicted to miss by 500 meters. And NASA has an in-progress experiment to measure how often the really small stuff hits: https://www.nasa.gov/mission_pages/station/research/news/sensor_to_monitor_orbital_debris_outside_ISS Sure, the chances of any given piece of debris hitting something is pretty low. But you get enough crap in orbit, the cumulative risk over time starts getting into territories that make your risk management team start drinking heavily. pgpdECQkDl7QG.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] anyone fiddlng with these?
On Thu, 15 Feb 2018 14:52:49 +0100, Toke Høiland-Jørgensen said: > How else would you make sure your toothbrush phoned home to the > mothership? > > https://gizmodo.com/the-house-that-spied-on-me-1822429852 Unless the mothership is the RPi3 sitting under my TV, I probably don't *want* it phoning home. And yes, I'm willing to pay extra for a toothbrush or light bulb or Roomba that can't be monetized because it only talks to a mothership that I control. pgpG207kJNUmp.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches than x86?
On Thu, 04 Jan 2018 13:40:28 -0800, Dave Taht said: > I guess I'm hoping for simple patches to the microcode to arrive next > week, even simply stuff to disable the branch predictor or speculative > execution, something simple, slow, and sane. In my inbox this morning. I have *no* idea why Intel is allegedly shipping a microcode fix for something believed to not be fixable via microcode. It may be this is a fix for only this one variant of the attack, and the other two require kernel hacks. Summary: An update for microcode_ctl is now available for Red Hat Enterprise Linux 7. Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section. The microcode_ctl packages provide microcode updates for Intel and AMD processors. Security Fix(es): * An industry-wide issue was found in the way many modern microprocessor designs have implemented speculative execution of instructions (a commonly used performance optimization). There are three primary variants of the issue which differ in the way the speculative execution can be exploited. Variant CVE-2017-5715 triggers the speculative execution by utilizing branch target It relies on the presence of a precisely-defined instruction sequence in the privileged code as well as the fact that memory accesses may cause allocation into the microprocessor's data cache even for speculatively executed instructions that never actually commit (retire). As a result, an unprivileged attacker could use this flaw to cross the syscall and guest/host boundaries and read privileged memory by conducting targeted cache side-channel attacks. (CVE-2017-5715) Note: This is the microcode counterpart of the CVE-2017-5715 kernel mitigation. injection. pgpxS6uvz9tTK.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] dnsmasq CVEs
On Sat, 07 Oct 2017 09:33:34 -0400, dpreed said: > They are not. The hardware designers at the chip and board level know little > or nothing about security techniques. They don't work with systems people who > build with their hardware to limit undefined or covert behaviors. It's worse than that. The hardware people are now intentionally building the chipsets with covert behavior baked right into the chip. Know how x86 people complain that SSM mode introduces jitter? That's just the tip of the iceberg. Believe it or not, there's an entire IPv4/IPv6 stack *and a webserver* hiding in there... https://schd.ws/hosted_files/ossna2017/91/Linuxcon%202017%20NERF.pdf Gaak. Have some strong adult beverage handy, you'll be needing it pgpfWdR9pZhVu.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] trying to make sense of what switch vendors say wrt buffer bloat
On Mon, 06 Jun 2016 11:29:38 -0400, Eric Johansson said: > Buffer bloat was a relevant on 10/100M switches, not 10Gb switches. At > 10Gb we can empty the queue in ~100ms The users we've got on 10Gb ports complain when their RTT hits 10ms. (And we've got plenty of boxes hanging on 40Gb ports. Not routers, servers. Fun fun fun) pgpcXsZct19_r.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] OK, what's the current recommendation(s)?
On Wed, 20 Apr 2016 16:48:51 -0700, Dave Taht said: > Can't recommend anything at $100 at the moment. The linksys 1200ac > comes closest. I have one running on a 125/25 connection using cake > just fine - but I can still pretty easily crash it on the wifi as of > openwrt trunk from a month back. The wifi is great while it lasts > tho Thanks for the pointer, poked around on Amazon and the OpenWRT site, the 1200AC looks like a workable choice feature-wise and for my bank account. Will probably go with that. Will probably flash the 3800 with openwrt 15.05 and benchmark it a bit before I replace it... pgpa44UdgDS_3.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [FCC] some comments from elsewhere on the lockdown
On Wed, 30 Sep 2015 16:11:38 -0400, Christopher Waid said: > > Apparently, they were of the opinion that the mere fact that I might > > die of a heart attack a year after distributing something doesn't > > excuse me from complying.) > > I don't know if it does excuse you from complying, but I say good luck > to the person trying to get it enforced. They could quite possibly hassle the executor of my estate if they were sufficiently determined. But given that abandonware (both software and hardware) is a big chunk of the problem, we really *do* need to address the problem of companies that can't provide patches because they've gone under. Possibly a requirement that they open-source the hardware/software if possible? (That's another can-o-worms - consider that a big chunk of why NVidia doesn't open-source their proprietary graphics drivers is because there's a lot of OpenGL-related patents and trade secrets that Microsoft bought when there was the big fire sale when SGI got out of the graphics market - so it's quite possible that a vendor *can't* open-source it when they go under due to licensing issues...) pgph8TIv8sRj4.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] some comments from elsewhere on the lockdown
On Fri, 25 Sep 2015 22:40:02 +0100, Dave Taht said: Sorry for late reply... > 2) Mandate that: the vendor supply a continuous update stream, one > that must respond to regulatory transgressions and CVEs within 45 days > of disclosure, for the warranted lifetime of the product + 5 years > after last customer ship. This needs to address vendors going out of business, and also corporate acquisitions. Bonus points for explaining how to deal with a CVE against hardware that's 7 years and 10 months out of production (3 years warranty + 5) - that requires a hardware engineering change to properly close. (I once got my chops busted by somebody from the GNU project over clause 3B of the GPLV2: b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, Apparently, they were of the opinion that the mere fact that I might die of a heart attack a year after distributing something doesn't excuse me from complying.) pgpAx2iDdcnJA.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Suggestions/advice for captive portal on gw00/gw10?
On Wed, 08 Apr 2015 16:40:10 -0400, leetminiwheat said: Sorry again, I found connlimit in iptables-mod-conntrack-extra. I'll investigate further about a simple portal and not make it too intrusive, just more of a warning that they're not on their (faster) home WiFi. It's 74F and sunny outside, it's one of the more scenic areas in southwest Virginia, I have a Jaguar with an almost full tank of gas in the parking lot, and I'm stuck in this cubicle for a bit longer. So the snark is running high at the moment. http://www.ex-parrot.com/pete/upside-down-ternet.html And add an exception list for device MAC addresses you recognize That should do the trick. :) pgpWgh_UQYEzF.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] DOCSIS 3+ recommendation?
On Mon, 16 Mar 2015 13:35:32 -0700, Matt Taggart said: Hi cerowrt-devel, My cable internet provider (Comcast) has been pestering me (monthly email and robocalls) to upgrade my cable modem to something newer. But I _like_ my current one (no wifi, battery backup) and it's been very stable and can handle the data rates I am paying for. But they are starting to roll out faster service plans and I guess it would be good to have that option (and eventually they will probably boost the speed of the plan I'm paying for). So... Any recommendations for cable modems that are known to be solid and less bufferbloated? I've been using the Motorola Surfboard SB6141 on Comcast with good results. Anybody got a good suggestion on how to test a cablemodem for bufferbloat, or what you can do about it anyhow (given that firmware is usually pushed from the ISP side)? pgpkXU3zCiBml.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [aqm] ping loss considered harmful
On Mon, 02 Mar 2015 11:17:33 +0100, Mikael Abrahamsson said: We have a huge amount of information in our TCP stacks that either are locked in there and not used properly to help users figure out what's going on, and there is basically zero information flow between the applications using TCP and the TCP stack itself. Each just tries to do its best on its own layer. You might want to touch base with the 'web10g' crew, who are working on instrumenting the Linux network stack to expose more of the inner variables for analysis and tuning. http://web10g.org/ pgpJFqrWhhsqu.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] MTU question
On Thu, 12 Feb 2015 13:46:47 -0800, David Lang said: It occured to me as I was driving home last night that if the APs are working to combine packets into a single transmission due to the high overhead of independent transmissions, would it possibly improve wifi performance to just configure a larger MTU? Has anyone done any experimentation in this area? It tends to totally ruin latency. Go read up on why things like ssh turn off Nagle. I have no reason to expect the same leaving stuff in a buffer while we wait for more data to make a full packet will work any better on Wifi. pgpOflR3mUwFo.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] DNSSEC
On Tue, 10 Feb 2015 16:57:07 -0800, Ranganathan Krishnan said: I am looking into ways to improve DNS on the openwireless router software. When I mentioned DNSSEC as one of the items to review, I received this response from one of the developers. http://sockpuppet.org/blog/2015/01/15/against-dnssec/ Right off the bat: But it doesn't make those attacks infeasible, so sites still need to adopt secure transports like TLS. With TLS properly configured, DNSSEC adds nothing. Which makes the rash assumption that it's appropriate to use TLS for everything. For starters, consider NTP or any other UDP-based system, or any TCP-based protocol that uses something other than TLS. Had DNSSEC been deployed 5 years ago, Muammar Gaddafi would have controlled BIT.LY's TLS keys. Actually, whoever controlled the master for .LY would have controlled BIT.LY, whether or not DNSSEC was in play. If Gaddafi had control of .LY, he could have redirected BIT.LY anywhere he wanted without keys, so the situation is no worse. What DNSSEC does is prevent a Gaddafi that *doesn't* control .LY from swiping control of your view of .LY (including BIT.LY) out from under you. Or your view of .COM, which would probably matter just a tad more to you... I'll let somebody else debunk the rest, I quit reading at that point. :) pgpJONJzBAuRh.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Recording RF management info _and_ associated traffic?
On Sun, 25 Jan 2015 20:39:23 -0800, David Lang said: Much as you may hate the abuse of standards and protocols that F5 and other load balancers use to trick both clients and servers into operating without knowing that there are multiple machines serving a website, they do make things a lot more better than if you tried make a website reliable and scale without them. Oh, I'm fully aware of that. We have several of the beasts across the hall from my office. :) pgp_eZH2qyzNg.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [discuss] [cdc_ncm] Refactoring cdc_ncm
On Mon, 19 Jan 2015 19:28:48 +0100, Enrico Mioso said: We are trying to change the way the cdc_ncm.c driver generate frames. We need to let it order parts of the packet in a different way. You're going to have to repeat that, and explain why you think re-ordering parts of the packet is going to work. (Hint - what happens when this packet with oddly ordered parts arrives at a host that is expecting RFC-standard ordering?) pgpzJSoTLSFKc.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Fwd: Announcing New airFiber24HD
On Wed, 17 Dec 2014 10:41:03 -0800, Dave Taht said: *15.9 bps/Hz* Spectral Efficiency. If they're using phase encoding or similar, that's pushing the ragged edge I think. Won't take much dip in the S/N before that comes back to bite you on the tookus, pgpkcQ2_dbafi.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] how is everyone's uptime?
On Wed, 10 Dec 2014 14:52:59 -0800, Dave Taht said: I am interested in long term memory leakage (run a free), process usage (runaways like pimd), and growth in disk space usage (df), so output like root@bogon-gateway-1:~# uptime 14:31:39 up 33 days, 8:50, load average: 0.02, 0.05, 0.05 root@bogon-gateway-1:~# free total used free shared buffers Mem:126256 100732255240 6156 -/+ buffers: 9457631680 Swap:000 root@bogon-gateway-1:~# df Filesystem 1K-blocks Used Available Use% Mounted on rootfs7296 392 6904 5% / /dev/root 7680 7680 0 100% /rom tmpfs63128 49364 13764 78% /tmp /dev/mtdblock57296 392 6904 5% /overlay overlayfs:/overlay7296 392 6904 5% / tmpfs 512 0 512 0% /dev Biggest issue after 33 days of uptime seems to be /tmp/log/babeld.log: root@bogon-gateway-1:~# ls -l /tmp/log/babeld.log -rw-r--r--1 root root 49416018 Dec 11 14:34 babeld.log root@bogon-gateway-1:~# wc /tmp/log/babeld.log 772310 6176740 49416530 /tmp/log/babeld.log root@bogon-gateway-1:~# sort /tmp/log/babeld.log | uniq -c Oh kewl. That seems to have killed it :) Uptime is now 11 minutes, and the log is much shorter. root@bogon-gateway-1:~# sort /tmp/log/babeld.log | uniq -c 107 Couldn't determine channel of interface sw00: Invalid argument. 107 Couldn't determine channel of interface sw10: Invalid argument. I'm trying to remember why I even want babeld running. In any case, the log as it stands now those two messages aren't much help. pgpN1ISysV42f.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] how is everyone's uptime?
On Thu, 11 Dec 2014 13:50:44 -0800, Dave Taht said: root@bogon-gateway-1:~# wc /tmp/log/babeld.log 772310 6176740 49416530 /tmp/log/babeld.log root@bogon-gateway-1:~# sort /tmp/log/babeld.log | uniq -c Oh kewl. That seems to have killed it :) Uptime is now 11 minutes, and the log is much shorter. Heh. Sorry! Not your fault. I don't think the design specs included have enough ram/swap to sort a 3/4 million line logfile :) More importantly, it rebooted cleanly and without hiccupping any connections through it. pgpvxE0oVI38F.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Fwd: Will Edwards to give Mill talk in Estonia on 12/10/2014
On Fri, 05 Dec 2014 11:18:57 -0800, Dave Taht said: The Mill is an extremely wide-issue VLIW design, able to issue 30+ MIMD operations per cycle. The Mill is inherently a vector machine and can vectorize and pipeline almost all loops in general purpose code. The big question is whether we know more about writing compilers for VLIW machines than we did when the Itanium came out. That was hard enough to get just 3 instructions packed per word (of course, the fact that it wasn't 3 generic instructions, but 2 of one flavor and 1 of another, didn't help). pgpYPoXRT9cjb.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] SQM in mainline openwrt, fq_codel considered for fedora default
On Tue, 21 Oct 2014 16:50:59 +0200, Michal Schmidt said: Suddenly? CONFIG_CGROUPS was systemd's requirement from its very beginning. It used to print: Failed to mount /sys/fs/cgroup: No such file or directory. and stop booting at this point. Actually, no. It *wasn't* there from its very beginning. See Fedora bug https://bugzilla.redhat.com/show_bug.cgi?id=628004 There was a period of time when it did *NOT* print that message and give you a hint of what was wrong. And an indicator of the problems with the systemd design team mentality is that the comment was be nice to Ingo Molnar, rather than admitting that yes, printing that the kernel didn't have a required feature might be a good idea (Yes, I personally got bit by this one myself...) pgpXcIXvgRftZ.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Fwd: next round of SQM changes
On Thu, 09 Oct 2014 22:37:30 +0200, Sebastian Moeller said: I am again in need of testers for SQM. Sure, what's needed to get the testable bits onto a 3.10.50-1 box? pgpr8SjZhldAC.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014
On Fri, 03 Oct 2014 05:28:35 -0400, Anders Kaseorg said: This bottom-up algorithm also seems to have a security problem thats just as bad as one with the top-down algorithm that you rejected below. Consider the same department.campus.university.edu example, where campus and edu are signed zones, and university is not a zone. This issue is why trust anchors were devised so people could start deploying DNSSEC before stuff like .COM got signed. pgpJd_yNtjpUu.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] cerowrt-3.10.50-1 released
On Mon, 28 Jul 2014 17:19:06 -0600, Jim Reisert AD1C said: Web page isn't working after upgrading (but the router seems to be): https://gw.home.lan:81/cgi-bin/luci Firefox can't establish a connection to the server at gw.home.lan:81. What happens if you use wget, curl, or even telnet? pgpa46m9yPzVl.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Ideas on how to simplify and popularize bufferbloat control for consideration.
On Sat, 24 May 2014 10:02:53 -0400, R. said: Further, this function could be auto-scheduled or made enabled on router boot up. Yeah, if such a thing worked, it would be good. (Note in the following that a big part of my *JOB* is doing What could possibly go wrong? analysis on mission-critical systems, which tends to color my viewpoint on projects. I still think the basic concept is good, just difficult to do, and am listing the obvious challenges for anybody brave enough to tackle it... :) I must be missing something important which prevents this. What is it? There's a few biggies. The first is what the linux-kernel calls -ENOPATCH - nobody's written the code. The second is you need an upstream target someplace to test against. You need to deal with both the server is unavalailable due to a backhoe incident 2 time zones away problem (which isn't *that* hard, just default to Something Not Obviously Bad(TM), and server is slashdotted (whci is a bit harder to deal with. Remember that there's some really odd corner cases to worry about - for instance, if there's a power failure in a town, then when the electric company restores power you're going to have every cerowrt box hit the server within a few seconds - all over the same uplink most likely. No good data can result from that... (Holy crap, it's been almost 3 decades since I first saw a Sun 3/280 server tank because 12 Sun 3/50s all rebooted over the network at once when building power was restored). And if you're in Izbekistan and the closest server netwise is at 60 Hudson, the analysis to compute the correct values becomes interesting. Dealing with non-obvious error conditions is also a challenge - a router may only boot once every few months. And if you happen to be booting just as a BGP routing flap is causing your traffic to take a vastly suboptimal path, you may end up encoding a vastly inaccurate setting and have it stuck there, causing suckage for non-obvious reasons for the non-technical, so you really don't want to enable auto-tuning unless you also have a good plan for auto-*RE*tuning pgpXtINEGfqKa.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [Bloat] Check out www.speedof.me - no Flash
On Fri, 25 Jul 2014 14:20:53 -0700, David Lang said: cost of bandwidth for this is just something to get someone to pay for (ideally someone with tons of bandwidth already who won't notice this sort of test, even if there are a few going on at once.) Ask U of Wisconsin how that worked out for them when Netgear shipped some new boxes http://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse#NETGEAR_and_the_University_of_Wisconsin.E2.80.93Madison It's one thing to come up with a solution that works for the 300 (total wild guess) people on this list. But to be useful for field deployable, it really needs to be able to handle a every Comcast customer in a major metro area, because we *do* want this stuff to work well when this makes it into the CPE that Comcast gives every new customer, right? :) pgpTONAFCaDF9.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] cerowrt-3.10.48-2 released
On Thu, 17 Jul 2014 15:18:31 -0700, Dave Taht said: Get it at: http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.10.48-2/ - I am focused on getting ready for ietf, and thus unable to give ipv6 a shakeout without risking my vpn failing while I'm away. Basic IPv6 is still functional, ssh smtp and http are all working for me over v6. So it's probably safe for you to leave for IETF. ;) pgpMoFkI2t_fO.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Fastpass: A Centralized Zero-Queue Datacenter Network
On Fri, 18 Jul 2014 16:20:28 -0700, David Lang said: not to mention the scalability issues in trying to get that info to a central point so that it can compute the N! possible paths for the data to take, along with the data from all the other systems to pack them most efficiently into the avilable paths. OK, so it converges slower than BGP. But at least it's not subject to wedgies. :) pgpcZEI0RmW2t.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] measuring bandwidth and latency with snmp
On Fri, 30 May 2014 23:05:24 -0700, Dave Taht said: There's no need to do ping.You can just measure the time it takes to issue and get the snmp query response. Am I missing something obvious? For devices with separate control and data planes, it's quite possible to have 3 different numbers: 1) The time it takes for the data plane to receive and forward a packet. 2) The time it takes for the data or control plane to generate an ICMP response 3) The time it takes for the control plane to do slowpath handling of a relatively heavy SNMP packet. It's why traceroute often gives you wonky timing numbers and reports RTTs to a middle hop are higher than to the destination. It's because the router was able to forward packets much faster than the slowpath to generate the ICMP TTL Exceeded reply For longer hauls, there's the added fun that the source and destination may not be in the same administrative domain - I have smokeping running on a Raspberry Pi to measure from local Comcast to work. My personal device and the work box in a different group are *never* going to speak SNMP to each other. :) pgp6UGIZq2164.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Ubiquiti QOS
On Sun, 25 May 2014 08:17:47 +0200, Dane Medic said: Is it true that devices with less than 64 MB can't handle QOS? - https://lists.chambana.net/pipermail/commotion-dev/2014-May/001816.html I'm not going to give one post on a list very much credence, especially when it doesn't contain a single actual fact or definitive claim. An explanation of exactly which data structure won't fit in 32M would be ideal. Even some numbers on RAM usage from /proc/slabinfo and a who ate all the frobozz slabs? would be better than what's in the post. pgp6zuyDtkid8.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] A stable cerowrt release in sight
On Thu, 15 May 2014 23:36:11 -0700, Dave Taht said: So hopefully the upcoming 3.10.40-4 build will be stable enough to freeze on. If there is anything else that people want done before freezing, let me know soonest. I just noticed a wait, what?. Luci is telling me: Hostnamebogon-gateway-1 Model NETGEAR WNDR3800 Firmware VersionCeroWrt Toronto 3.10.40-4 / LuCI Trunk (git-c5a9089) Kernel Version 3.10.36 Local Time Sun May 18 09:44:00 2014 Uptime 1d 12h 36m 54s and sure enough, ssh'ing in I see: root@bogon-gateway-1:~# uname -a Linux bogon-gateway-1 3.10.36 #1 Fri May 16 01:00:30 PDT 2014 mips GNU/Linux Something has gone astray somewhere... pgpPTaWzZyqXu.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] A stable cerowrt release in sight
On Thu, 15 May 2014 23:36:11 -0700, Dave Taht said: So hopefully the upcoming 3.10.40-4 build will be stable enough to freeze on. If there is anything else that people want done before freezing, let me know soonest. Upgraded just fine for me, been running for several hours on a wndr3800 without any big problems. Minor nit 1: It doesn't seem to save the 'Start UPNP now' setting, so that's something I need to re-set each time I upgrade. Seems to have been this way for a long time, 3.10.32-9 did it to me too. My PS3 says UPNP works once I start it. Minor nit 2: It grants IPv4 leases for 24 hours, but IPv6 for only 1 hour. That's OK - except my laptop running Fedora seems to think the lease is for 24 hours, not 1, so the lease ends up expiring. Haven't chased this to see who's to blame. It's not a show stopper for me, because my laptop's SLAAC-autoconfigured address and RFC3041 privacy addresses keep working anyhow. It's probably been as long as the other one, pgpuyU3Hq9AlO.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [Bloat] fq_codel is two years old
On Thu, 15 May 2014 16:32:55 -0400, dpr...@reed.com said: And in the end of the day, the problem is congestion, which is very non-linear. There is almost no congestion at almost all places in the Internet at any particular time. You can't fix congestion locally - you have to slow down the sources across all of the edge of the Internet, quickly. There's a second very important point that somebody mentioned on the NANOG list a while ago: If the local router/net/link/whatever isn't congested, QoS cannot do anything to improve life for anybody. If there *is* congestion, QoS can only improve your service to the normal uncongested state - and it can *only do so by making somebody else's experience suck more* pgp85Eljwtkbm.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
[Cerowrt-devel] Administrivia - is the download server ill?
Seeing this the last few days trying to reach the repository: % ping snapon.lab.bufferbloat.net PING snapon.lab.bufferbloat.net (149.20.63.30) 56(84) bytes of data. From int-0-0-1-0.r1.sql1.isc.org (149.20.65.10) icmp_seq=1 Destination Host Unreachable ^C --- snapon.lab.bufferbloat.net ping statistics --- 10 packets transmitted, 0 received, +1 errors, 100% packet loss, time 9463ms Hopefully it's just the hamsters escaped for the weekend and weren't turning those wheels pgp8xt4Db7R6M.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] 3.10.38-1 sysupgrade not working
On Mon, 28 Apr 2014 20:56:45 -0700, Justin Madru said: I'm trying to flash the new version (3.10.38-1) using the openwrt-ar71xx-generic-wndr3800-squashfs-sysupgrade.bin image, but I'm getting the following error in the web ui. The uploaded image file does not contain a supported format. Make sure that you choose the generic image format for your platform. Ah.. somebody else with the problem :) Following up on my previous testing - I was on 36-3, and 36-4 and 38-1 both failed with that same error. So as suggested by somebody, I scp'ed the 38-1 over to my 3800, and I got the following results from the command line: First, try in 'test' mode - this returned *very* fast, as in sub-second: root@bogon-gateway-1:~# sysupgrade -d 60 -v -T /tmp/openwrt-ar71xx-generic-wndr3800-squashfs-sysupgrade.bin and no output. So then try for real - and that worked and rebooted to 38-1 with all my config settings preserved. Not sure what the TRX header issue is - but it seemed to come far too late in the process to explain my problems with Luci. root@bogon-gateway-1:~# sysupgrade -d 60 -v /tmp/openwrt-ar71xx-generic-wndr380 0-squashfs-sysupgrade.bin Saving config files... etc/xinetd.conf etc/sysctl.conf etc/shells etc/shadow etc/rc.local etc/profile etc/passwd etc/opkg.conf etc/lighttpd/lighttpd.conf etc/inittab etc/hosts etc/group etc/fw_env.config etc/firewall.user etc/dropbear/dropbear_rsa_host_key etc/dropbear/dropbear_dss_host_key etc/dropbear/authorized_keys etc/dnsmasq.conf etc/crontabs/root etc/config/wol etc/config/wireless etc/config/upnpd etc/config/ucitrack etc/config/ubootenv etc/config/transmission etc/config/system etc/config/sqm etc/config/snmpd etc/config/samba etc/config/radvd etc/config/qos etc/config/polipo etc/config/network etc/config/natpmp etc/config/minissdpd etc/config/luci etc/config/fstab etc/config/firewall etc/config/etherwake etc/config/dropbear etc/config/dhcp6c etc/config/dhcp etc/config/debloat etc/config/ddns etc/config/bcp38 etc/config/babeld etc/config/aqm etc/config/alttcp etc/config/ahcpd etc/config/6relayd etc/babeld.conf etc/avahi/avahi-daemon.conf killall: watchdog: no process killed Sending TERM to remaining processes ... lighttpd logd netifd odhcpd lighttpd cro nd snmpd pimd xinetd dbus-daemon smbd nmbd avahi-daemon babeld ahcpd rngd ntpd d nsmasq ubusd askfirst miniupnpd Sending KILL to remaining processes ... askfirst Switching to ramdisk... Performing system upgrade... Unlocking firmware ... Writing from stdin to firmware ... Appending jffs2 data from /tmp/sysupgrade.tgz to firmware...TRX header not found Error fixing up TRX header Upgrade completed Rebooting system... (And when it came back, it was on 38-1. Pondering /rom/usr/lib/lua/luci/view/admin_system/flashops.htm didn't help much. Down around line 83 we have this: % if image_invalid then % iv class=cbi-section-error%:The uploaded image file does not contain a supported format. Make sure that you choose the generic image format f % end % but damned if I can figure out where/how image_invalid gets set on return from the 'form method=post' above it pgpiTOshCSWdc.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Full blown DNSSEC by default?
On Sun, 20 Apr 2014 10:01:45 -0400, Chuck Anderson said:
The first effect of using a client-side DNSSEC validator is that
gw.home.lan doesn't work:
Apr 20 00:12:32 a unbound[1885]: [1885:1] info: validation failure
gw.home.lan. A IN: no NSEC3 records from 172.30.42.65 for DS lan. while
building chain of trust
To make this work, you have to tell unbound that home.lan is an
insecure domain:
unbound-control insecure_add home.lan.
Ouch.
This wouldn't be so bad, if there was some way to tell it to believe
*your* instance of home.lan, but not trust the babbling of any other
instance you might come across. What we *really* want to do with unbound
is this stuff in the unbound.conf file:
trust-anchor-file: filename
File with trusted keys for validation. Both DS and DNSKEY
entries can appear in the file. The format of the file is the
standard DNS Zone file format. Default is , or no trust
anchor file.
auto-trust-anchor-file: filename
File with trust anchor for one zone, which is tracked with
RFC5011 probes. The probes are several times per month, thus
the machine must be online frequently. The initial file can be
one with contents as described in trust-anchor-file. The file
is written to when the anchor is updated, so the unbound user
must have write permission.
trust-anchor: Resource Record
A DS or DNSKEY RR for a key to use for validation. Multiple
entries can be given to specify multiple trusted keys, in addiâ
tion to the trust-anchor-files. The resource record is entered
in the same format as 'dig' or 'drill' prints them, the same
format as in the zone file. Has to be on a single line, with
around it. A TTL can be specified for ease of cut and paste, but
is ignored. A class can be specified, but class IN is default.
trusted-keys-file: filename
File with trusted keys for validation. Specify more than one
file with several entries, one file per entry. Like
trust-anchor-file but has a different file format. Format is
BIND-9 style format, the trusted-keys { name flag proto algo
key; }; clauses are read. It is possible to use wildcards
with this statement, the wildcard is expanded on start and on
reload.
Having said that, I admit not having in hand an easy way to feed unbound
the needed info. Not sure if 'dig home.lan ds trust-anchor-here' will do
it, as the unbound on my laptop isn't configured to talk to DNS learned via
DHCP, so home.lan doesn't resolve at all for me...
pgpaHTSoUtmcS.pgp
Description: PGP signature
___
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
On Sat, 12 Apr 2014 22:28:49 +0200, Sebastian Moeller said: scp /path/to/the/sysupgrade/image.bin r...@gw.home.lan:/tmp ssh r...@gw.home.lan cd /tmp sysupgrade -n -d 60 -v ./image.bin I wish to apologize for not testing it yet - I was on a working 36-3 image and didn't dare break it as I was doing prep work for today's software and firmware upgrades for several petabytes of storage... pgpcVpauWzIst.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] cerowrt-3.10.36-4 released
On Wed, 09 Apr 2014 23:45:23 -0700, Dave Taht said: + dnsmasq 2.69 with dnssec enabled by default + possible workaround for wifi bug #442 in increased qlen_* + fix for ipv6 access to https://gw.home.lan:81 + fresh merge with opewrt + update to 2048 bit cert generation + fix for openssl heartbleed (fix also in -3) bug + tested for an hour + change to sqm to basically always use simplest.qos on inbound - I'm very, very, very, very, very, very, very, very, very tired. I really hope this results in a stable cerowrt. Please beat the hell out of it. Trying to flash openwrt-ar71xx-generic-wndr3800-squashfs-sysupgrade.bin gets me this message at the bottom of the screen: The uploaded image file does not contain a supported format. Make sure that you choose the generic image format for your platform. Looks like something in Luci is busted, as trying to re-upload a 3.10.36-3 image blows chunks with the exact same error message, and -3 is what I'm already running Any debugging guesses? My first guess was a full filesystem, but: root@bogon-gateway-1:~# df Filesystem 1K-blocks Used Available Use% Mounted on rootfs7424 388 7036 5% / /dev/root 7424 7424 0 100% /rom tmpfs63132 4368 58764 7% /tmp /dev/mtdblock57424 388 7036 5% /overlay overlayfs:/overlay7424 388 7036 5% / tmpfs 512 0 512 0% /dev there's plenty of room in /tmp to pull down an 8M image and work on it? pgppB40CBn_Qr.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] cerowrt-3.10.36-4 released
On Thu, 10 Apr 2014 18:48:20 +0200, Toke Høiland-Jørgensen said: You could try manually scp'ing the image over and running sysupgrade via the command line? OK.. Thanks for the hint. Will try that tonight... pgpmJS0ZD6Wal.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Fwd: [uknof] CVE-2014-0160 mitigation using iptables
On Wed, 09 Apr 2014 08:18:23 -0700, Dave Taht said: It is not clear if this could be used to protect things inside the firewall (switching to a forward rather than input table), nor if it could be used with ipv6. It will require adjusting the 52= in the rule, but otherwise should be OK for IPv6. For that matter, the ruleset as given is probably busticated when IP or TCP options are present, because it assumes a hard-coded offset. pgpiixPwMfafT.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [Bug #442] wifi fails to transmit traffic after a few hours
On Sat, 05 Apr 2014 09:33:45 -0700, Dave Taht said: The above subject line and cc will get this conversation into the bug tracker. I've never managed to have the wifi lock up on my 3800. root@bogon-gateway-1:~# cat /etc/openwrt_release DISTRIB_ID=CeroWrt DISTRIB_RELEASE=3.10.36-1 DISTRIB_REVISION=r40387 DISTRIB_CODENAME=toronto DISTRIB_TARGET=ar71xx/generic DISTRIB_DESCRIPTION=CeroWrt Toronto 3.10.36-1 DISTRIB_TAINTS=no-all busybox root@bogon-gateway-1:~# uptime 20:53:11 up 3:05, load average: 0.16, 0.30, 0.39 root@bogon-gateway-1:~# egrep -i country|channel|htmode /etc/config/wireless option channel '11' option country 'US' option channel '36' option country 'US' (Upstream to comcast is a nominal 10mbit down/2 mbit up) root@bogon-gateway-1:~# sh ./betterspeedtest.sh -H netperf6.richb-hanover.com Testing against netperf6.richb-hanover.com while pinging gstatic.com (60 seconds in each direction) . Download: 7.66 Mbps Latency: (in msec, 61 pings, 0.00% packet loss) Min: 16.824 10pct: 20.281 Median: 24.838 Avg: 25.469 90pct: 30.937 Max: 37.476 . Upload: 2.21 Mbps Latency: (in msec, 61 pings, 0.00% packet loss) Min: 19.125 10pct: 21.770 Median: 26.363 Avg: 26.392 90pct: 30.478 Max: 34.852 root@bogon-gateway-1:~# sh ./betterspeedtest.sh -H netperf.richb-hanover.com Testing against netperf.richb-hanover.com while pinging gstatic.com (60 seconds in each direction) Download: 8.09 Mbps Latency: (in msec, 61 pings, 0.00% packet loss) Min: 17.153 10pct: 20.290 Median: 24.304 Avg: 24.855 90pct: 29.817 Max: 40.293 . Upload: 2.24 Mbps Latency: (in msec, 61 pings, 0.00% packet loss) Min: 21.306 10pct: 23.127 Median: 25.968 Avg: 26.374 90pct: 30.681 Max: 33.517 pgp808bKTDJYi.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] odhcp6c went crazy flooding Comcast with DHCPv6 SOLICITs
On Tue, 25 Mar 2014 20:41:53 -0700, Dave Taht said: I'm still at a loss as to the most correct way to bring up dnssec. Don't sweat it too much - nobody else in the security business knows how to do it either. :) DNSSEC has even less uptake than IPv6 pgpTOPz42zAEl.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] DNSSEC NTP Bootstrapping
On Mon, 24 Mar 2014 08:29:16 -0400, Chuck Anderson said: How about writing an RFC to define a well-known NTP anycast address and using that as a fallback? This is a problem that needs to be solved for the larger internet community, not just CeroWRT/OpenWRT. Using a well-known anycast address for NTP is somewhat problematic for security. It's possible to secure anycast DNS using DNSSEC - but the NTP crypto isn't suitable for securing an anycast mode. Fortunately, for many use cases, we can probably rely on the upstream provider to hand us an NTP server address in a DHCP extension. If you're willing to trust the *rest* of that DHCP response, you may as well trust the NTP server it points you at. I admit not having a clever idea for the non-DHCP case though... pgp1f9ykIO4Tz.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] cerowrt-3.10.32-12 released
On Fri, 21 Mar 2014 17:47:42 -, Dave Taht said: - currently untested (but a really small delta from -10 and -11) + Resync with openwrt head + dnsmasq 2.69rc1 (close approximation thereof) + This is the first release with toke's bcp38 code installed (and enabled by default). I am hoping people simply don't even notice it's there... (it's off the firewall web page) Seems to be working for me on a 3800 on both IPv4 and IPv6 here in Comcast-land. Admittedly not stress-tested much, that will probably have to wait for some evening this week... pgpFv4u3A7m4z.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] cerowrt-3.10.32-9 released
On Tue, 18 Mar 2014 11:35:51 -0400, Dave Taht said: second note is that the wndr can only forward packets at about 330Mbit without firewall rules. Add in the firewall rules and you are looking at sub 120mbit forwarding performance. It's good to know that it can handle any connection I'm likely to get from Comcast in the reasonable future. :) pgpx2hSw_bwX1.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] cerowrt-3.10.32-9 released
On Sun, 16 Mar 2014 12:58:28 -0700, Dave Taht said: Get it at: http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.10.32-9/ - untested with ipv6 as yet Running it on my 3800, IPv6 from my laptop to Google and work and other places seems to be working just fine in my corner of Comcast land. My laptop gets a DHCPv6 address, a SLAAC address, and generates itself a privacy address, and they all are reachable from the outside, and my Rasberry Pi is happily SLAAC'ing away as well. As far as I can tell, my TV and my PS3 are IPv4-only, so that's as much as I can test. If I catch it misbehaving, or there's something in particular you want poked, yell... pgpgBqHcyZxH9.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
[Cerowrt-devel] 3.10.28-14 - notes so far...
1) Upgraded from a 3.10.26-1 without any major issues. 2) The Luci 'Software' tab fails with these messages when I click on Update Lists: Downloading http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.10.28-14/packages/Packages.gz. Updated list of available packages in /var/opkg-lists/london. Downloading http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.10.28-14/packages/Packages.sig. Signature check failed. Remove wrong Signature file. Collected errors: * opkg_verify_file: Verification failure. 3) 6relayd doesn't get installed by default. Due to (2), it's loads of fun to get it installed, since it doesn't show up on the 'Available packages' tab (I ended up wget'ing it, untar'ing it, and then untar'ing the data.tar.gz file). Is there a way to install a local *.ipk ? 4) Once 6relayd gets installed, this /etc/config/6relayd Just Works(tm) on Comcast residential cables in my area: config server default option master ge00 list networkge01 list networkgw00 list networkgw01 list networkgw10 list networkgw11 list networkse00 list networksw00 list networksw10 option rd server option dhcpv6 server option fallback_relay 'rd dhcpv6 ndp' option management_level 1 pgpmQEaKfE0Vj.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
