On Wed, Jan 15, 2014 at 7:27 AM, David Personette <dper...@gmail.com> wrote:
> On Tue, Jan 14, 2014 at 11:11 PM, Dave Taht <dave.t...@gmail.com> wrote:
>>
>> On Tue, Jan 14, 2014 at 7:36 AM, David Personette <dper...@gmail.com>
>> wrote:
>> > On Tue, Jan 14, 2014 at 1:07 AM, Dave Taht <dave.t...@gmail.com> wrote:
>> there is btw, a fix for setting mcast_rates in 3.10.26-1. I have long
>> thought
>> that we should *default* to a higher rate (9mbits for 2.4ghz and 12 for
>> 5 ghz) as freifunk does for each ssid, for multicast. This will knock weak
>> signal'd devices off the network entirely, but minimize the impact of
>> multicast on everyone else.
>>
>> " hostapd: fix mcast_rate setting
>>
>> Introduced by ("netifd: add wireless configuration support and
>> port mac80211 to
>> the new framework")
>>
>> Reported-by: René van Weert <r.vanwe...@sowifi.com>
>> Signed-off-by: Antonio Quartulli <anto...@meshcoding.com>
>> "
>>
>> to test that, add a option mcast_rate 9000 under each wifi-iface stanza
>> in /etc/config/wireless.
>>
>> You can do things like fiddle with mdns-scan on your client to see if that
>> works better/faster or worse
>
>
> I've added your recommended "option mcast_rate 9000" to the 2.4 ghz and
> "option mcast_rate 12000" to the 5 ghz. I'll reboot the router in a bit
> (random other services aren't happy after a network restart; where random ==
> I don't remember what breaks).
>
>>
>> >>
>> >> ** BCP38 compliance
>> >> Cerowrt does not currently stop unknown rfc1918 addresses from going
>> >> out
>> >> ge00.
>> >> ** Squash incoming diffserv bits
>> >> many providers pee on the diffserv bits. It would be good to detect it
>> >> and reset to BE incoming packets. (note: IPv6 is far less peed on.).
>> >> There was a nice idea discussed last year on using conntrack to match
>> >> incoming with outgoing diffserv bits.
>> >
>> >
>> > I'd added this into my /etc/firewall.user.
I went and looked over the firewall stuff in cero and this stanza was missing.
So it isn't getting called.
# include a file with users custom iptables rules
config include
option path /etc/firewall.user
>> I'd be happy to work on
>> > adding it
>> > into the official script if you would like. I'm a sysadmin, what
>> > development
>> > skills I have are in scripting.
>>
>> Which part? is it possible to squash just the diffserv and not the ecn
>> bits?
>>
>> iptables and ipv6tables lines appreciated.
>>
>> Also additional suggestions for firewall rules appreciated.
>>
>> One thing I added to simple.qos in the last go round was deprioritizing
>> icmp a bit post-wondershaper-rant.
>>
>> # ICMP traffic - Don't impress your friends. Deoptimize to manage ping
>> floods
>> # better instead
>>
>> $TC filter add dev $IFACE parent 1:0 protocol ip prio 8 \
>> u32 match ip protocol 1 0xff flowid 1:13
>>
>> $TC filter add dev $IFACE parent 1:0 protocol ipv6 prio 9 \
>> u32 match ip protocol 1 0xff flowid 1:13
>
>
> Sorry, didn't trim quite enough to designate what I was replying to, I had
> meant that I added the rfc1918 egress blocking to my /etc/firewall.user. But
> I do have a few lines (that I thought came from this mailing list) for
> cleaning up diffserv bits. Although looking at the output of 'iptables -S'
> now, I'm not sure that it's even doing what the original author intended.
> Instead of three dscp classes (which iptables accepts without throwing an
> error), it seems to only keep one of them in the ACCEPT line... it will
> probably have to be broken out into multiple lines. If it's even doing what
> you were interested in, in the first place.
Please note it's also been a really long time since I touched iptables...
so everything I write below could be wrong. While the rest of you lovable
crazies are putting this stuff on your main gw I'm usually in a lab
with all the firewalls off internally, doing benchmarks....
> ### Configure both IPv4 and IPv6
> ipt() {
> iptables $*
> ip6tables $*
> }
> # iptables doesn't support an inverted match
> # ipt -t mangle -A PREROUTING -m dscp ! --dscp-class AF11,AF21,BE -j DSCP \
> # --set-dscp-class BE
> ipt -t mangle -N FIX_TOS
> ipt -t mangle -A FIX_TOS -m dscp --dscp-class AF11,AF21,BE -j ACCEPT
I sure wish/hope that works. Otherwise writing 23 firewall rules is kind of hard
on iptables. Definately incomplete otherwise...
> ipt -t mangle -A FIX_TOS -j DSCP --set-dscp-class BE
What I see is a ton of CS1 traffic that I don't think originated that way.
I don't mind re-marking CS1 traffic to be BE on entry, and then applying
local rules (trying to match torrent for example)
I think this needs to happen only on exiting the ge00 interface
on entry. We want to not mangle our own diffserv domain.
> for i in sw00 sw10 gw00 gw10 gw01 gw11; do
> ipt -t mangle -A POSTROUTING -o $i -j FIX_TOS
> done
So a change to:
ipt -t mangle -A PREROUTING -i ge00 -j FIX_TOS
?
moving onto bcp38...
http://tools.ietf.org/html/bcp38
> # Create a rfc1918 IP filter
> iptables -N grey
> iptables -A grey -s 172.30.42.0/24 -j ACCEPT
> iptables -A grey -s 10.0.0.0/8 -j DROP
> iptables -A grey -s 127.0.0.0/8 -j DROP
> iptables -A grey -s 172.16.0.0/12 -j DROP
> iptables -A grey -s 192.168.0.0/16 -j DROP
> iptables -A grey -s 169.254.0.0/16 -j DROP
> iptables -I delegate_forward 4 -o ge00 -j grey
1) We have a problem is that bcp38 should not be on by default
in a double nat situation. Or at least be more clever and grok if
it's external interface is a rfc1918 address that it should be allowed
to send to it. Or punt and not enable bcp38 in a double nat situation.
2) Is there BCP38 for ipv6? I know the default rules for hurricane
"do the right thing", but native?
3) At least in my networks I use 172.x subnets heavily
4) And ipset is available. I don't know if the gui supports it or what the
difference in speed would be by traversing this many rules.
Moving onto a different thought on a slightly different topic
I think something like this should be a defined rule in the
/etc/config/firewall so that missing hosts get information back...
(untested)
iptables -N noegress
iptables -A noegress -d 10.0.0.0/8 -j REJECT # with destination
unreachable somehow
iptables -A noegress -d 127.0.0.0/8 -j REJECT
iptables -A noegress -d 172.16.0.0/12 -j REJECT
iptables -A noegress -d 192.168.0.0/16 -j REJECT
iptables -A noegress -d 169.254.0.0/16 -j REJECT
iptables -I delegate_forward 4 -o ge00 -j noegress #here? why this rule?
>
>>
>> >>
>> >> ** SSL support for the configuration interfaces
>> >> All the plumbing exists for this in cero, it just has to be made to
>> >> work. the key generation routine needs to be fixed in uci-defaults and
>> >> lighttpd config updated. It's embarrassing to not have SSL running.
>> >
>> >
>> > If it's scripting and web server config, I'll work on this too.
>>
>> GOFERIT! The cert generation is just plain wrong for lighttpd...
>> controlled by this
>> file... (which vanishes after boot)
>>
>>
>> https://github.com/dtaht/cerofiles-next/blob/cerowrt-next/files/etc/uci-defaults/make-certs.sh
>>
>> and could use to get re-run out of cron or something after sufficient
>> randomness has been generated
>> to ensure a decent cert.
>>
>> and lightttpd doesn't seem to like the generated cert or trying to
>> listen with ssl enabled on
>> https://cerowrt.local:81 (yes, I'd like to keep using a weird port
>> number for the admin
>> interface)
>>
>> I don't mind shipping openssl rather than pxg if that's what's needed
>> to generate a valid
>> cert.
>
>
> I'll start working on it. Thanks.
>
>>
>> >>
>> >> * Bufferbloat.net problems
>> >> the bufferbloat.net servers are undermaintained and obsolete. I long
>> >> ago swapped out my sysadmin and ruby skills for other things.
>> >>
>> >> ** huchra replacement (one disk currently crashed, the other going)
>> >> In addition to running this mailing list this used to be 1/5th of the
>> >> openwrt build cluster.
>> >>
>> >> lists needs to move to a virtual server ASAP.
>> >>
>> >> openwrt could really use a good build cluster. been running most of
>> >> theirs now for a couple years, out of machines pulled from the junk
>> >> bin.
>> >>
>> >> ** Web Site updates
>> >> the redmine implementation on bufferbloat.net has been overrrun by
>> >> spam and I stopped
>> >> accepting new contributors that didn't contact me also via email
>> >> long ago.
>> >>
>> >> given how hard it would be to update the present website, perhaps
>> >> moving to cerowrt.org
>> >> on a virtual server will be simpler.
>> >
>> >
>> > This I can work on now, if you like, I can spin up a Digital Ocean VM
>> > that
>> > should be able to run a mailing list with no problems. Getting Postfix
>> > setup
>> > should be a snap, I'm not sure what else is needed for the mailing list,
>> > but
>> > we can discuss it off the mailing list.
>>
>> I can free up some time to work on this fairly soon. Let me know when
>> you can set aside a few hours (I am presently on EST)
>>
>> > Did you want a new name or keep
>> > huchra for the VM? Once it's up, getting a list of needed software from
>> > huchra, certs, and the data can be synced over, do some testing, then
>> > the
>> > DNS A and MX records can be updated.
>>
>> Oh, that would be nice. We haven't had anybody caring for the servers
>> since
>> Richard Pitt left us...
>>
>> The other big problem is updating from an ancient version of redmine +
>> postgres to chilliproject + postgres.
>>
>> > Hmm, just saw that Digital Ocean still doesn't have IPv6 yet. Will that
>> > be a
>> > problem? Any other suggestions for hosting it? I've used them for
>> > several
>> > little projects, they have a good interface and rates, IMHO. Thanks.
>>
>> Yep, need ipv6. I have a pair of linode instances spun up but have
>> never done anything with them aside from use them as targets
>> for rrul tests. One is in NJ, the other in england. Linode seems
>> competent...
>
>
> I have nothing against Linode's service. The nice things about DigitalOcean
> are: all SSD storage, and their rates are about half Linode. Linode offers
> more CPUs at each node size however, and has functional IPv6 (which I
> thought that they would have straightened out by now *SIGH*).
>
> I'm eastern time too. I'm get off work at 17:30, but can probably work in an
> extra meeting during the day if it works out better for you. I'm off next
> couple of Mondays so have a 3 day weekends to work on things in. You can
> reach me via email, gtalk, "hangouts", and I'll be glad to give you my POTS
> numbers on a medium that can't easily be harvested by bots.
>
> --
> David P.
>
--
Dave Täht
Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
