[Cerowrt-devel] cerowrt-3.10.32-12 released

[Cerowrt-devel] cerowrt-3.10.32-12 released

[Dave Taht]

-  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)

The only problems I foresee happening are

1) some devices are dependent on double-nat to be configurable -
notably most cable modems depend on 192.168.100.1 to get configured
the first time. I thought about adding that in as a default exception,
and still may.

2) People using this on an interior gateway on a complex network will
need to either disable bcp38 or (preferably) add their rfc1918
network(s) to the exception list on the interior gateway (not on the
external gateway). For example, the yurtlab lives on subnets
172.21.0.0/20.

3) I am not prescient, however, and the only way to find out what
problems will be created is to inflict it on^H^H^H^H^H^H^H kindly ask
the cerowrt userbase to try it.

- Jim Gettys tells me that after a day or so of heavy use of
3.10.32-9, the 2.4ghz radio gets thoroughly wedged after a succession
of DMA tx errors and only a reboot can clear it.

I am in the process of rebuilding the yurtlab and can get back into
heavy wifi testing over the next week or so. In the interim,
please beat up wifi any way you can...

I would really like to get to a stable beta release by the end of the month.






-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] cerowrt-3.10.32-12 released

[Toke Høiland-Jørgensen]

[-- Attachment #1: Type: text/plain, Size: 794 bytes --]

Dave Taht <dave.taht@gmail.com> writes:

> 2) People using this on an interior gateway on a complex network will
> need to either disable bcp38 or (preferably) add their rfc1918
> network(s) to the exception list on the interior gateway (not on the
> external gateway). For example, the yurtlab lives on subnets
> 172.21.0.0/20.

Well, depending on the topology it might not be needed. There's an
auto-detection mechanism built-in which tries to auto-detect the
upstream network settings. So as long as you only need to access one
upstream subnet, no configuration change is needed.

If it does *not* work, I'd appreciate seeing the output of the following
commands to try to improve the auto-detection feature:

ipset list
ip route
ip addr

along with the network that's being blocked.

-Toke

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

Re: [Cerowrt-devel] cerowrt-3.10.32-12 released

[Sebastian Moeller]

Hi Dave,

wow, after enabling NDP-Proxy 'hybrid mode' (on sw10), for the first time, my macbook got working ipv6 through cerowrt. (My setup is a bit peculiar as the primary router gets a /56 from the ISP but only hands out /64s, don't ask me why). Now I need to understand why this does not work for SW00 or SE00, but these are peanuts now :)


On Mar 21, 2014, at 18:47 , Dave Taht <dave.taht@gmail.com> wrote:

> -  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)

	I did not notice this even though my primary router furnishes cerowrt with 192.168.2.104 (but no additional subnets in there), the internet works and I can reach machines in the primary subnet just fine, so nothing to see here ;) Greart work Dave and Toke. 

> 
> The only problems I foresee happening are
> 
> 1) some devices are dependent on double-nat to be configurable -
> notably most cable modems depend on 192.168.100.1 to get configured
> the first time. I thought about adding that in as a default exception,
> and still may.

	I seem to recall that there is a page in the openwrt wiki about how to enable that access, which is quite involved (for a layman), so having cerowrt solve this problem in a better fashion would be much appreciated.

> 
> 2) People using this on an interior gateway on a complex network will
> need to either disable bcp38 or (preferably) add their rfc1918
> network(s) to the exception list on the interior gateway (not on the
> external gateway). For example, the yurtlab lives on subnets
> 172.21.0.0/20.

	I guess having an easy way to set exceptions is really a good solution.

> 
> 3) I am not prescient, however, and the only way to find out what
> problems will be created is to inflict it on^H^H^H^H^H^H^H kindly ask
> the cerowrt userbase to try it.

	Tried it, seems to work.

> 
> - Jim Gettys tells me that after a day or so of heavy use of
> 3.10.32-9, the 2.4ghz radio gets thoroughly wedged after a succession
> of DMA tx errors and only a reboot can clear it.

	With 3.10.32-9 I could het the usual TX hangs on both radio0 and radio1 by running RRUL against cerowrt (on a wndr3700v2), I did not manage to actually wedge either radio so I had to reboot though.

From (on the 5GHz radio):
bash-3.2$ date ; ./netperf-wrapper --ipv4 -l 300 -H gw.home.lan rrul -p all_scaled --disable-log -t noAQM_noLLA_16M2M_hms-beagle_2_nacktmulle
Fri Mar 21 22:50:17 CET 2014

root@nacktmulle:~#dmesg
[...]
[ 3466.207031] ath: phy1: Failed to stop TX DMA, queues=0x00e!
[ 3485.308593] ath: phy1: Failed to stop TX DMA, queues=0x00e!
[ 3511.449218] ath: phy1: Failed to stop TX DMA, queues=0x00e!
[ 3513.500000] ath: phy1: Failed to stop TX DMA, queues=0x00e!
[ 3545.664062] ath: phy1: Failed to stop TX DMA, queues=0x00e!
[ 3561.769531] ath: phy1: Failed to stop TX DMA, queues=0x00e!
[ 3591.925781] ath: phy1: Failed to stop TX DMA, queues=0x00e!
[ 3615.042968] ath: phy1: Failed to stop TX DMA, queues=0x00a!
[ 3630.140625] ath: phy1: Failed to stop TX DMA, queues=0x00e!
[ 3663.308593] ath: phy1: Failed to stop TX DMA, queues=0x00e!
[ 3666.351562] ath: phy1: Failed to stop TX DMA, queues=0x00e!
[ 3688.468750] ath: phy1: Failed to stop TX DMA, queues=0x00e!
[ 3701.585937] ath: phy1: Failed to stop TX DMA, queues=0x00e!
root@nacktmulle:~# cat /sys/kernel/debug/ieee80211/phy1/ath9k/reset
    Baseband Hang:  0
Baseband Watchdog:  0
   Fatal HW Error:  0
      TX HW error:  0
     TX Path Hang: 25
      PLL RX Hang:  0
         MAC Hang:  0
     Stuck Beacon:  0
        MCI Reset:  0

But that is not any different from earlier cerowrt versions...
	

> 
> I am in the process of rebuilding the yurtlab and can get back into
> heavy wifi testing over the next week or so. In the interim,
> please beat up wifi any way you can…

	Ah, okay so now I will switch to the 2,4GHz radio to see whether I can wedge that…

best regards & many thanks
	Sebastian

> 
> I would really like to get to a stable beta release by the end of the month.
> 
> 
> 
> 
> 
> 
> -- 
> 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

Re: [Cerowrt-devel] cerowrt-3.10.32-12 released

[Toke Høiland-Jørgensen]

[-- Attachment #1: Type: text/plain, Size: 722 bytes --]

Sebastian Moeller <moeller0@gmx.de> writes:

>       I did not notice this even though my primary router furnishes
> cerowrt with 192.168.2.104 (but no additional subnets in there), the
> internet works and I can reach machines in the primary subnet just
> fine, so nothing to see here ;) Greart work Dave and Toke.

Yay!

Just to confirm:

1. What is the output of `ipset list` on the router?

2. What happens if you ping 192.168.1.1 (or some other address in a
private subnet, but not configured on any of your interfaces)?

> 	I guess having an easy way to set exceptions is really a good
> 	solution.

There's a BCP38 tab in the firewall config that allows you to input
subnet exceptions manually if needed. :)

-Toke

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

Re: [Cerowrt-devel] cerowrt-3.10.32-12 released

[Sebastian Moeller]

On Mar 21, 2014, at 23:53 , Toke Høiland-Jørgensen <toke@toke.dk> wrote:

> Sebastian Moeller <moeller0@gmx.de> writes:
> 
>>      I did not notice this even though my primary router furnishes
>> cerowrt with 192.168.2.104 (but no additional subnets in there), the
>> internet works and I can reach machines in the primary subnet just
>> fine, so nothing to see here ;) Greart work Dave and Toke.
> 
> Yay!
> 
> Just to confirm:
> 
> 1. What is the output of `ipset list` on the router?

root@nacktmulle:~# ipset list
Name: bcp38-ipv4
Type: hash:net
Revision: 4
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 8856
References: 2
Members:
127.0.0.0/8
192.168.2.0/24 nomatch
172.16.0.0/12
10.0.0.0/8
192.0.2.0/24
169.254.0.0/16
240.0.0.0/4
198.51.100.0/24
203.0.113.0/24
0.0.0.0/8
192.168.0.0/16
root@nacktmulle:~# 


> 
> 2. What happens if you ping 192.168.1.1 (or some other address in a
> private subnet, but not configured on any of your interfaces)?

root@nacktmulle:~# ping -c 1 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
ping: sendto: Operation not permitted


For comparison the primary router:
root@nacktmulle:~# ping -c 1 192.168.2.1
PING 192.168.2.1 (192.168.2.1): 56 data bytes
64 bytes from 192.168.2.1: seq=0 ttl=64 time=0.849 ms

--- 192.168.2.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.849/0.849/0.849 ms
root@nacktmulle:~# 


And from my macbook on SW00:

hms-beagle:~ moeller$ ping -c 1 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
92 bytes from 172.30.42.65: Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 5400 d987   0 0000  3f  01 0a0a 172.30.42.80  192.168.1.1 


--- 192.168.1.1 ping statistics ---
1 packets transmitted, 0 packets received, 100.0% packet loss
hms-beagle:~ moeller$ ping -c 1 192.168.2.1
PING 192.168.2.1 (192.168.2.1): 56 data bytes
64 bytes from 192.168.2.1: icmp_seq=0 ttl=63 time=3.993 ms

--- 192.168.2.1 ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 3.993/3.993/3.993/0.000 ms
hms-beagle:~ moeller$ 

After white-listing 192.168.1.0/24
hms-beagle:~ moeller$ ping -c 1 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes

--- 192.168.1.1 ping statistics ---
1 packets transmitted, 0 packets received, 100.0% packet loss
hms-beagle:~ moeller$ 

After deletion of the exemption it is back again to "Destination Net Unreachable"


It just seems to work, and well at that.


> 
>> 	I guess having an easy way to set exceptions is really a good
>> 	solution.
> 
> There's a BCP38 tab in the firewall config that allows you to input
> subnet exceptions manually if needed. :)
	I guess I should have been clearer in my comment; what I wanted to say is that it is great that you actually offer this ;). (Tiny note: if there is only one member in the white-list the GUI only shows the add button and no delete button, just deleting the contents does work though)

Best Regards
	Sebastian

> 
> -Toke

Re: [Cerowrt-devel] cerowrt-3.10.32-12 released

[Toke Høiland-Jørgensen]

[-- Attachment #1: Type: text/plain, Size: 820 bytes --]

Sebastian Moeller <moeller0@gmx.de> writes:

> It just seems to work, and well at that.

Wow, great! I expected it to break in horrible ways I had not thought
of... Thanks for testing! :)

> 	I guess I should have been clearer in my comment; what I wanted to say
> is that it is great that you actually offer this ;).

Ah, I see :)

> (Tiny note: if there is only one member in the white-list the GUI only
> shows the add button and no delete button, just deleting the contents
> does work though)

Yeah, that seems to be an idiosyncrasy of the luci gui that I'm
declaring it firmly out of scope for this to fix. ;)

A general fix might be useful, though. Should probably be fixed in the
Luci javascript (/www/luci-static/resources/cbi.js on the router) -- not
really sure what the right behaviour is, though...?

-Toke

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

Re: [Cerowrt-devel] cerowrt-3.10.32-12 released

[Toke Høiland-Jørgensen]

[-- Attachment #1: Type: text/plain, Size: 4114 bytes --]

Sebastian Moeller <moeller0@gmx.de> writes:

> I have a question about the reasoning behind the whole thing though. I
> can see that not permitting source addresses that do not belong to
> cerowrt's subnets makes a ton of sense. But what precisely is the
> reasoning to not route the private addresses?

Well, for IPv6, not permitting valid source addresses is exactly how
this is implemented -- by having source-based routing for the assigned
prefixes (I suppose you could do a similar private address blocking
thing for IPv6, but I punted on that for now; and don't think it's as
important). However, for IPv4 the question of "which addresses are
valid" becomes harder to answer in anything but the simple case of "one
network behind the router". I.e. for mesh networks etc.

At the same time, in general, egress traffic from the home network could
conceivably go anywhere, so blocking on destination is not viable
either. Except, basically, for the networks being blocked by the current
implementation; these are all defined by various RFCs (most well-known
probably RFC1918) to be invalid on the internet, and so can be safely
dropped. And since all sorts of equipment probe the default addresses
(think users on a new net trying to find their home gateway at
192.168.1.1, devices that think they are on a VPN but are really not,
etc), so packets leaking onto the internet can be quite common, and they
can go a surprisingly long way before being dropped, I'm told.

> Or, asked differently, what harm does it to route those except wasting
> a bit of bandwidth; but since the src is correct it will be relatively
> easy to pinpoint malicious sources that way?

Well, a DDOS is just a lot of people "wasting a bit of bandwidth"... ;)

Really, though, BCP38 (which, btw, is a Best Current Practice document
From the IETF: http://tools.ietf.org/html/bcp38) should be implemented
by ISPs to be really effective in DOS mitigation. I think implementing
it in cerowrt (apart from the "be secure by default" goal) is to
demonstrate that it's possible to do a workable solution (trough ipsets)
that doesn't involve traversing a bunch of slow firewall rules, and so
doesn't impact performance noticeably. You know, the old clue-bat ;)


> The point I wanted to make is that following
> http://wiki.openwrt.org/doc/howto/access.modem.through.nat is a bit
> more involved than what should be required from the typical home user.

Yeah, I can see that. It would probably be possible to do some
autodetection (perhaps by crowdsourcing a database of likely modem
addresses), but I fear the implementation would be annoyingly complex.
In the perfect world, you could just arping each of the addresses and
see if they reply, but I have this nagging feeling that the kind of
equipment we want to talk to will do things like refuse to reply to ARP
unless the request comes from within its own (probably hard-coded)
subnet. In which case we would have to assign a bunch of addresses on
the upstream interface to do the probing, then remove them again,
leaving to all sorts of annoying potential failure modes... :(

> Your implementation is so straight forward I could talk my siblings
> though over the phone, so it passes my ad-hoc tests for viability in
> the real world ;)

Haha, great! Sometimes I think someone should write up a formal document
on the "non-technical family member" test...

> So on several other pages (like
> https://gw.home.lan:81/cgi-bin/luci/;stok=e2041363b170e62aa756a4ee3e525f72/admin/network/hosts)
> the GUI is used slightly different, there is one fixed add button and
> each entry always comes with its own delete button. I have not looked
> at the luci code for that though.

Well I didn't do a lot of research on luci primitives for this, but did
come across that one. That widget is a different one that mirrors a
different configuration primitive (adding config *sections* rather than
a list of config *entries*). I don't *think* there's a better widget for
the lists, but would be happy to be proved wrong :)

-Toke

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

Re: [Cerowrt-devel] cerowrt-3.10.32-12 released

[Dave Taht]

On Sat, Mar 22, 2014 at 11:08 AM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> Sebastian Moeller <moeller0@gmx.de> writes:
>
>> I have a question about the reasoning behind the whole thing though. I
>> can see that not permitting source addresses that do not belong to
>> cerowrt's subnets makes a ton of sense. But what precisely is the
>> reasoning to not route the private addresses?
>
> Well, for IPv6, not permitting valid source addresses is exactly how
> this is implemented -- by having source-based routing for the assigned
> prefixes (I suppose you could do a similar private address blocking
> thing for IPv6, but I punted on that for now; and don't think it's as
> important). However, for IPv4 the question of "which addresses are
> valid" becomes harder to answer in anything but the simple case of "one
> network behind the router". I.e. for mesh networks etc.
>
> At the same time, in general, egress traffic from the home network could
> conceivably go anywhere, so blocking on destination is not viable
> either. Except, basically, for the networks being blocked by the current
> implementation; these are all defined by various RFCs (most well-known
> probably RFC1918) to be invalid on the internet, and so can be safely
> dropped. And since all sorts of equipment probe the default addresses
> (think users on a new net trying to find their home gateway at
> 192.168.1.1, devices that think they are on a VPN but are really not,
> etc), so packets leaking onto the internet can be quite common, and they
> can go a surprisingly long way before being dropped, I'm told.

0) I've seen 5 hops or more before they die.

I have observed 3 use cases in the last couple years personally.

1) In the campground I have a primary dns server that frequently drops
off the (routed) network. 2 minutes later, all queries directed at that dns
server start going out the default gateway, with no reply. with this code
in place, they get stopped at the edge, with an appropriate reply, and when
the server comes back online they are responded to normally. win.

2) I have seen many worms banging away at everything in every subnet
they can find, and several that just arbitrarily bang away at 192.168.x.y.
in cero's case these not only eat external bandwidth but interact badly with the
"fast queue" concept - as being sparse, they are optimized to go out the
router first, and never return....

3) In a data center I have seen multiple attempts by sources with
invalid return addresses to leverage dns reflection attacks. Dropping
totally invalid addresses is a win...

That said, the primary purpose of this code is to supply a tool and clue
to places that could do this sort of filtering better inside their network.
small corporate campuses, isps, etc.

>> Or, asked differently what harm does it to route those except wasting
>> a bit of bandwidth; but since the src is correct it will be relatively
>> easy to pinpoint malicious sources that way?
>
> Well, a DDOS is just a lot of people "wasting a bit of bandwidth"... ;)

Lack of universal BCP38 has cost a lot of dns managers a lot of hair,
and more recently the ntp ddos was pretty bad.

> Really, though, BCP38 (which, btw, is a Best Current Practice document
> From the IETF: http://tools.ietf.org/html/bcp38) should be implemented
> by ISPs to be really effective in DOS mitigation. I think implementing
> it in cerowrt (apart from the "be secure by default" goal) is to
> demonstrate that it's possible to do a workable solution (trough ipsets)
> that doesn't involve traversing a bunch of slow firewall rules, and so
> doesn't impact performance noticeably. You know, the old clue-bat ;)

Perhaps this is a new logo idea for cero: A giant clue-bat.

>
>> The point I wanted to make is that following
>> http://wiki.openwrt.org/doc/howto/access.modem.through.nat is a bit
>> more involved than what should be required from the typical home user.
>
> Yeah, I can see that. It would probably be possible to do some
> autodetection (perhaps by crowdsourcing a database of likely modem
> addresses), but I fear the implementation would be annoyingly complex.
> In the perfect world, you could just arping each of the addresses and
> see if they reply, but I have this nagging feeling that the kind of
> equipment we want to talk to will do things like refuse to reply to ARP
> unless the request comes from within its own (probably hard-coded)
> subnet. In which case we would have to assign a bunch of addresses on
> the upstream interface to do the probing, then remove them again,
> leaving to all sorts of annoying potential failure modes... :(

Well, a brute force way would be to insert all these addresses with
say a one hour timeout to expire on a cold boot.

>> Your implementation is so straight forward I could talk my siblings
>> though over the phone, so it passes my ad-hoc tests for viability in
>> the real world ;)
>
> Haha, great! Sometimes I think someone should write up a formal document
> on the "non-technical family member" test...

+1

>> So on several other pages (like
>> https://gw.home.lan:81/cgi-bin/luci/;stok=e2041363b170e62aa756a4ee3e525f72/admin/network/hosts)
>> the GUI is used slightly different, there is one fixed add button and
>> each entry always comes with its own delete button. I have not looked
>> at the luci code for that though.
>
> Well I didn't do a lot of research on luci primitives for this, but did
> come across that one. That widget is a different one that mirrors a
> different configuration primitive (adding config *sections* rather than
> a list of config *entries*). I don't *think* there's a better widget for
> the lists, but would be happy to be proved wrong :)

In terms of featureitus it might be nice to have a comment field shown
in the gui and in the config file.
>
> -Toke
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] cerowrt-3.10.32-12 released

[Toke Høiland-Jørgensen]

[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]

Dave Taht <dave.taht@gmail.com> writes:

> Perhaps this is a new logo idea for cero: A giant clue-bat.

That'd be cool. I've always wondered what a clue-bat would actually look
like... :)

> Well, a brute force way would be to insert all these addresses with
> say a one hour timeout to expire on a cold boot.

Yeah, but then you'd have to handle collisions with subnets configured
on the internal interface and all sorts of weird edge cases, I'm sure...

Perhaps some sort of feasibility study on the arping approach could be
conducted? Someone with a cable modem who can check if `arping <addr>`
with its configuration address returns anything when no corresponding
address is configured on the router? Or am I completely off base in
thinking that would work?

> In terms of featureitus it might be nice to have a comment field shown
> in the gui and in the config file.

Right, well if you don't mind restructuring the config file completely
in a non-backwards-compatible way, it would be pretty easy to give it a
section for each subnet, with an associated comment / name field,
and use the same widget as the hostname setup. Would make the config
file significantly more verbose, though, and also harder to read IMO...

-Toke

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

Re: [Cerowrt-devel] cerowrt-3.10.32-12 released

[Sebastian Moeller]

Hi Toke,

On Mar 22, 2014, at 12:08 , Toke Høiland-Jørgensen <toke@toke.dk> wrote:

> Sebastian Moeller <moeller0@gmx.de> writes:
> 
>> I have a question about the reasoning behind the whole thing though. I
>> can see that not permitting source addresses that do not belong to
>> cerowrt's subnets makes a ton of sense. But what precisely is the
>> reasoning to not route the private addresses?
> 
> Well, for IPv6, not permitting valid source addresses is exactly how
> this is implemented -- by having source-based routing for the assigned
> prefixes (I suppose you could do a similar private address blocking
> thing for IPv6, but I punted on that for now; and don't think it's as
> important). However, for IPv4 the question of "which addresses are
> valid" becomes harder to answer in anything but the simple case of "one
> network behind the router". I.e. for mesh networks etc.
> 
> At the same time, in general, egress traffic from the home network could
> conceivably go anywhere, so blocking on destination is not viable
> either. Except, basically, for the networks being blocked by the current
> implementation; these are all defined by various RFCs (most well-known
> probably RFC1918) to be invalid on the internet, and so can be safely
> dropped. And since all sorts of equipment probe the default addresses
> (think users on a new net trying to find their home gateway at
> 192.168.1.1, devices that think they are on a VPN but are really not,
> etc), so packets leaking onto the internet can be quite common, and they
> can go a surprisingly long way before being dropped, I'm told.

	Ah, thanks for the information.

> 
>> Or, asked differently, what harm does it to route those except wasting
>> a bit of bandwidth; but since the src is correct it will be relatively
>> easy to pinpoint malicious sources that way?
> 
> Well, a DDOS is just a lot of people "wasting a bit of bandwidth"... ;)

	I had not looked at it from that perspective, makes a lot of sense...

> 
> Really, though, BCP38 (which, btw, is a Best Current Practice document
> From the IETF: http://tools.ietf.org/html/bcp38) should be implemented
> by ISPs to be really effective in DOS mitigation. I think implementing
> it in cerowrt (apart from the "be secure by default" goal) is to
> demonstrate that it's possible to do a workable solution (trough ipsets)
> that doesn't involve traversing a bunch of slow firewall rules, and so
> doesn't impact performance noticeably. You know, the old clue-bat ;)
> 
> 
>> The point I wanted to make is that following
>> http://wiki.openwrt.org/doc/howto/access.modem.through.nat is a bit
>> more involved than what should be required from the typical home user.
> 
> Yeah, I can see that. It would probably be possible to do some
> autodetection (perhaps by crowdsourcing a database of likely modem
> addresses), but I fear the implementation would be annoyingly complex.
> In the perfect world, you could just arping each of the addresses and
> see if they reply, but I have this nagging feeling that the kind of
> equipment we want to talk to will do things like refuse to reply to ARP
> unless the request comes from within its own (probably hard-coded)
> subnet. In which case we would have to assign a bunch of addresses on
> the upstream interface to do the probing, then remove them again,
> leaving to all sorts of annoying potential failure modes... :(
> 
>> Your implementation is so straight forward I could talk my siblings
>> though over the phone, so it passes my ad-hoc tests for viability in
>> the real world ;)
> 
> Haha, great! Sometimes I think someone should write up a formal document
> on the "non-technical family member" test...
> 
>> So on several other pages (like
>> https://gw.home.lan:81/cgi-bin/luci/;stok=e2041363b170e62aa756a4ee3e525f72/admin/network/hosts)
>> the GUI is used slightly different, there is one fixed add button and
>> each entry always comes with its own delete button. I have not looked
>> at the luci code for that though.
> 
> Well I didn't do a lot of research on luci primitives for this, but did
> come across that one. That widget is a different one that mirrors a
> different configuration primitive (adding config *sections* rather than
> a list of config *entries*). I don't *think* there's a better widget for
> the lists, but would be happy to be proved wrong :)

	I thought a bit about this, and I think there might be a way to use the available widgets in a way that emulates consistency ;) (well at least in theory)
If the first entry would not hog the singleton entry field with the add button, but would spawn a new empty field with an add button, while the just entered (and saved & applied) entry would be followed by the delete button, he whole thing would be consistent enough to not confuse the user. I will see whether I can implement that in the luci code.

Best Regards
	Sebastian

> 
> -Toke

Re: [Cerowrt-devel] cerowrt-3.10.32-12 released

[Toke Høiland-Jørgensen]

[-- Attachment #1: Type: text/plain, Size: 636 bytes --]

Sebastian Moeller <moeller0@gmx.de> writes:

> I thought a bit about this, and I think there might be a way to use
> the available widgets in a way that emulates consistency ;) (well at
> least in theory) If the first entry would not hog the singleton entry
> field with the add button, but would spawn a new empty field with an
> add button, while the just entered (and saved & applied) entry would
> be followed by the delete button, he whole thing would be consistent
> enough to not confuse the user. I will see whether I can implement
> that in the luci code.

Cool; FWIW, I think it's the javascript you need to look at :)

-Toke

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

Re: [Cerowrt-devel] cerowrt-3.10.32-12 released

[Sebastian Moeller]

Hi Dave,

On Mar 22, 2014, at 18:09 , Dave Taht <dave.taht@gmail.com> wrote:

> On Sat, Mar 22, 2014 at 11:08 AM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>> Sebastian Moeller <moeller0@gmx.de> writes:
>> 
>>> I have a question about the reasoning behind the whole thing though. I
>>> can see that not permitting source addresses that do not belong to
>>> cerowrt's subnets makes a ton of sense. But what precisely is the
>>> reasoning to not route the private addresses?
>> 
>> Well, for IPv6, not permitting valid source addresses is exactly how
>> this is implemented -- by having source-based routing for the assigned
>> prefixes (I suppose you could do a similar private address blocking
>> thing for IPv6, but I punted on that for now; and don't think it's as
>> important). However, for IPv4 the question of "which addresses are
>> valid" becomes harder to answer in anything but the simple case of "one
>> network behind the router". I.e. for mesh networks etc.
>> 
>> At the same time, in general, egress traffic from the home network could
>> conceivably go anywhere, so blocking on destination is not viable
>> either. Except, basically, for the networks being blocked by the current
>> implementation; these are all defined by various RFCs (most well-known
>> probably RFC1918) to be invalid on the internet, and so can be safely
>> dropped. And since all sorts of equipment probe the default addresses
>> (think users on a new net trying to find their home gateway at
>> 192.168.1.1, devices that think they are on a VPN but are really not,
>> etc), so packets leaking onto the internet can be quite common, and they
>> can go a surprisingly long way before being dropped, I'm told.
> 
> 0) I've seen 5 hops or more before they die.
> 
> I have observed 3 use cases in the last couple years personally.
> 
> 1) In the campground I have a primary dns server that frequently drops
> off the (routed) network. 2 minutes later, all queries directed at that dns
> server start going out the default gateway, with no reply. with this code
> in place, they get stopped at the edge, with an appropriate reply, and when
> the server comes back online they are responded to normally. win.

	This makes a lot of sense, thanks.

> 
> 2) I have seen many worms banging away at everything in every subnet
> they can find, and several that just arbitrarily bang away at 192.168.x.y.
> in cero's case these not only eat external bandwidth but interact badly with the
> "fast queue" concept - as being sparse, they are optimized to go out the
> router first, and never return….

	"Automatic worm deprioritization", we should pass this onto the marketing department ;) Kidding aside, again makes a ton of sense.

> 
> 3) In a data center I have seen multiple attempts by sources with
> invalid return addresses to leverage dns reflection attacks. Dropping
> totally invalid addresses is a win…

	And even more sense. I guess I am glad I posed the question, since I learned a lot...

> 
> That said, the primary purpose of this code is to supply a tool and clue
> to places that could do this sort of filtering better inside their network.
> small corporate campuses, isps, etc.
> 
>>> Or, asked differently what harm does it to route those except wasting
>>> a bit of bandwidth; but since the src is correct it will be relatively
>>> easy to pinpoint malicious sources that way?
>> 
>> Well, a DDOS is just a lot of people "wasting a bit of bandwidth"... ;)
> 
> Lack of universal BCP38 has cost a lot of dns managers a lot of hair,
> and more recently the ntp ddos was pretty bad.
> 
>> Really, though, BCP38 (which, btw, is a Best Current Practice document
>> From the IETF: http://tools.ietf.org/html/bcp38) should be implemented
>> by ISPs to be really effective in DOS mitigation. I think implementing
>> it in cerowrt (apart from the "be secure by default" goal) is to
>> demonstrate that it's possible to do a workable solution (trough ipsets)
>> that doesn't involve traversing a bunch of slow firewall rules, and so
>> doesn't impact performance noticeably. You know, the old clue-bat ;)
> 
> Perhaps this is a new logo idea for cero: A giant clue-bat.

	Is that bat as in micro/macrochiroptera ( http://en.wikipedia.org/wiki/Bat ) or as in http://en.wikipedia.org/wiki/Baseball_bat, I assume the latter but the former would allow more leeway for the potential logo ;)

> 
>> 
>>> The point I wanted to make is that following
>>> http://wiki.openwrt.org/doc/howto/access.modem.through.nat is a bit
>>> more involved than what should be required from the typical home user.
>> 
>> Yeah, I can see that. It would probably be possible to do some
>> autodetection (perhaps by crowdsourcing a database of likely modem
>> addresses), but I fear the implementation would be annoyingly complex.
>> In the perfect world, you could just arping each of the addresses and
>> see if they reply, but I have this nagging feeling that the kind of
>> equipment we want to talk to will do things like refuse to reply to ARP
>> unless the request comes from within its own (probably hard-coded)
>> subnet. In which case we would have to assign a bunch of addresses on
>> the upstream interface to do the probing, then remove them again,
>> leaving to all sorts of annoying potential failure modes... :(
> 
> Well, a brute force way would be to insert all these addresses with
> say a one hour timeout to expire on a cold boot.

	I think requiring the user to add the specific address in the white-list is not a bad way, as long as it is prominently documented. I assume most users will not care anyway and those that are should not mind following simple easy instructions.

Best Regards
	Sebastian

> 
>>> Your implementation is so straight forward I could talk my siblings
>>> though over the phone, so it passes my ad-hoc tests for viability in
>>> the real world ;)
>> 
>> Haha, great! Sometimes I think someone should write up a formal document
>> on the "non-technical family member" test...
> 
> +1
> 
>>> So on several other pages (like
>>> https://gw.home.lan:81/cgi-bin/luci/;stok=e2041363b170e62aa756a4ee3e525f72/admin/network/hosts)
>>> the GUI is used slightly different, there is one fixed add button and
>>> each entry always comes with its own delete button. I have not looked
>>> at the luci code for that though.
>> 
>> Well I didn't do a lot of research on luci primitives for this, but did
>> come across that one. That widget is a different one that mirrors a
>> different configuration primitive (adding config *sections* rather than
>> a list of config *entries*). I don't *think* there's a better widget for
>> the lists, but would be happy to be proved wrong :)
> 
> In terms of featureitus it might be nice to have a comment field shown
> in the gui and in the config file.
>> 
>> -Toke
>> 
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>> 
> 
> 
> 
> -- 
> Dave Täht
> 
> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] cerowrt-3.10.32-12 released

[Sebastian Moeller]

Hi Toke,


On Mar 22, 2014, at 20:36 , Toke Høiland-Jørgensen <toke@toke.dk> wrote:

> Sebastian Moeller <moeller0@gmx.de> writes:
> 
>> I thought a bit about this, and I think there might be a way to use
>> the available widgets in a way that emulates consistency ;) (well at
>> least in theory) If the first entry would not hog the singleton entry
>> field with the add button, but would spawn a new empty field with an
>> add button, while the just entered (and saved & applied) entry would
>> be followed by the delete button, he whole thing would be consistent
>> enough to not confuse the user. I will see whether I can implement
>> that in the luci code.
> 
> Cool; FWIW, I think it's the javascript you need to look at :)

	I hope to avoid that, I have zero contact with javascript so far and if I can avoid the learning curve I happily do so ;) But eta see whether I can fake it in luci/lua…

Best Regards
	Sebastian

> 
> -Toke

Re: [Cerowrt-devel] cerowrt-3.10.32-12 released

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 575 bytes --]

On Fri, 21 Mar 2014 17:47:42 -0000, 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...

[-- Attachment #2: Type: application/pgp-signature, Size: 848 bytes --]

Re: [Cerowrt-devel] cerowrt-3.10.32-12 released

[Jim Reisert AD1C]

On Sun, Mar 23, 2014 at 6:56 PM, <Valdis.Kletnieks@vt.edu> wrote:

> 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...

No problems to report here either.

Incidentally my older Sony Blu-Ray player connected to the -guest
network at 172.30.43.x (with subnet mask 255.255.255.0) with no
problems at all reaching the Internet.  So Sony must have the CIDR
issue in more than one of their products.

-- 
Jim Reisert AD1C, <jjreisert@alum.mit.edu>, http://www.ad1c.us

[Cerowrt-devel] upnp oddness (was Re: cerowrt-3.10.32-12 released

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 694 bytes --]

On Fri, 21 Mar 2014 17:47:42 -0000, Dave Taht said:
> -  currently untested (but a really small delta from -10 and -11)

Not sure if it's a bug or pilot error, but..

after flashing -12,  upnp didn't get restarted. I did a 'test network
connection' from my PS3, which reported it wasn't available. Went to the
page on the web admin, and sure enough the 'start upnp' button was off.
Re-clicked it, hit 'save and apply' and it started working and the PS3
said it had UPNP and Type 2 NAT, so it was happy.

I seem to recall doing this same tap-dance after installing -9.
My first guess is that variable isn't flagged for whatever the "save
config values" across an upgrade does...


[-- Attachment #2: Type: application/pgp-signature, Size: 848 bytes --]

Re: [Cerowrt-devel] cerowrt-3.10.32-12 released

[Kai Yang]

[-- Attachment #1: Type: text/plain, Size: 1040 bytes --]

Was dlna ever working across wifi and wired? Tried this build and my
readynas media server is not discoverable on wifi. Testing with Ubuntu and
upnp-inspector.


On Mon, Mar 24, 2014 at 10:35 AM, Jim Reisert AD1C
<jjreisert@alum.mit.edu>wrote:

> On Sun, Mar 23, 2014 at 6:56 PM, <Valdis.Kletnieks@vt.edu> wrote:
>
> > 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...
>
> No problems to report here either.
>
> Incidentally my older Sony Blu-Ray player connected to the -guest
> network at 172.30.43.x (with subnet mask 255.255.255.0) with no
> problems at all reaching the Internet.  So Sony must have the CIDR
> issue in more than one of their products.
>
> --
> Jim Reisert AD1C, <jjreisert@alum.mit.edu>, http://www.ad1c.us
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>

[-- Attachment #2: Type: text/html, Size: 1832 bytes --]