[Cerowrt-users] Setting up bridging and debugging problems with LAN ports with WNDR3800

[Dave Taht]

On Mon, Nov 19, 2012 at 6:55 PM, Marc MERLIN <marc at merlins.org> wrote:
> On Sat, Nov 17, 2012 at 03:44:37PM -0800, Marc MERLIN wrote:
>> Ok, it's a bit long, sorry, I spent too many hours today trying to fix some
>> issues in cerowrt and get bridging working.
>>
>> This is cerowrt 3.3.8-26.
>>
>> Before I get to bridging, openwrt could get my ethernet LAN ports working if I
>> recall correcly, but it seems that cerowrt can't (the WAN port is ok, and so
>> is wireless, but none of my LAN ports seem to be able to send IP traffic
>> even though I see STP and other traffic from them).
>>
>> The first issue is while I had wireless working, wired just wasn't.
>> I never got an IP on wired ports, and for that matter when I forced the IP
>> on my laptop, I couldn't ping the interface
>
> Ok, after a full reset it worked again and I figured out what the problem
> is.
> If you enable VLAN functionality in network/switch, the LAN ports stop
> working even if they are marked as 'untagged' which is the default.
> When I used tcpdump, I did look for whether there was a tagging problem,
> but the packets didn't seem tagged.
> But it gets worse, even after turning vlan off in the GUI
> config switch
>         option enable_vlan4k '1'
> stays and prevents the LAN ports from working.
> Actually, also
>         option enable_vlan '0'
> needs to be restored and without that line, your LAN ports just will not
> work.

I can't remember what the option is, but it helps to turn on jumbo
frames. This cuts the buffering in the switch down to something less
unreasonable.

> That's a pretty bad GUI trap, 4H of my time down the drain :(

I'm glad that you got somewhere and documented it publicly.

>> > Question #1:
>> What am I doing wrong or how do I debug further?
>
> There wasn't much to find, this required wiping everything, starting over,
> taking config diffs, finding the option that broke everything, and further
> finding that unchecking the GUI option didn't clean the config file enough
> to recover.

that was a deep hole dug!

>
>> > Question #4:
>> how do I get debugging/logs from dnsmasq? Is it done through syslog?
>
> logread or logread -f
>
>> > Question #5:
>> Why can't I get the :81 web interface to respond on its outside IP (kind of
>> useful when I'm mucking on the internal one).
>> /etc/lighttpd/lighttpd.conf says:
>> ## bind to port (default: 80)
>> server.port = 81
>
> 81 is firewalled off on the ge00 interface.

I might argue it be firewalled off from wifi entirely, too. The reason
why it isn't is that I fairly often have to reflash a large number of
routers, remotely, which tends to blow up something or another, and
it's helpful to be able to get back into the wifi side.

(this is horribly understaffed research project. Security is a concern
(see the xinet.d stuff) but first up is making the network behave
better.)

>> > Question #6:
>> Why is the admin interface on :81 not using https?
>
> Seems that openwrt didn't seem to hink it was a good idea.

The problem here is threefold:

1) The amount of available randomness (entropy) in the linux kernel,
on an embedded device, is nearly nil. This has all sorts of bad
side-effects.

We've had multiple cases where routers generated the same ssh key, for example.

This is quite scary to me, as 10s of millions of commercial devices
with lousy entropy and yet supposedly secure "wpa2" are shipping in
the field.

While cerowrt contains a few patches intended to increase entropy,
they were far from satisfactory. Even with the merge of the new random
number code from 3.6, multiple device drivers need to be enhanced
before it's truly useful, and I'll remain unhappy until I find a
device with hardware RNG, or am convinced enough entropy is wedged
into the pool on boot to be random enough.

2) For doing https, there are two solutions. A) create a self signed
SSL key on first boot. This has the problems of 1, above, and
additionally causes your browser to throw an error saying it's a self
signed key, even though, normally, self signed keys are more secure
than anything else, as the various breaks in the chain of trust via
conventional authorities shows.

B) ship with a per router key that is the same on all firmware. This
is not horrible, in conjunction with C). Pretty horrible without.

C) somehow acquire a ssl key on first boot. Unfortunately you are not
connected to anything on first boot, you need a key. And automating
key creation and signing is something of a problem, when you don't
control a certificate authority and have secure paths in the first
place.

Sigh.

https IS supported in the web server and the only problem with
enabling it are the problems noted above.

I felt that it was best to not "lie" about the level of security by
using https, and try to firewall off the core interfaces, more than
pursue either of these alternatives. That said, I'd like to make https
available by default, and if I just had that hardware rng or trust in
the new 3.6 based randomness code, I'd do so in a heartbeat with a
self signed key.


>
> Marc
> --
> "A mouse is a device used to point at the xterm you want to type in" - A.S.R.
> Microsoft is to operating systems ....
>                                       .... what McDonalds is to gourmet cooking
> Home page: http://marc.merlins.org/
> _______________________________________________
> Cerowrt-users mailing list
> Cerowrt-users at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-users



-- 
Dave Täht

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