From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 9235121F107 for ; Mon, 19 Nov 2012 10:15:37 -0800 (PST) Received: by mail-ie0-f171.google.com with SMTP id 17so2285634iea.16 for ; Mon, 19 Nov 2012 10:15:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=AavCyT07PiONoyWXd6cE8XWLlimUzHjPfALiO7hrAjc=; b=wIAzsJVIiPMRshBwj9pcMxL0XY4dTLWZoc4EHtGz9voF79kjcicnRRdWG3ZIbo1rbv MGKE5nqQV9I78VPUMzwkmHvzaovsJ21J0xTnUVyOKXC+IlaqnT0hXmZEZe167iFziX3P TPUWgh8NzEi217SXKz1t/39RUYouCkSPsSarN0oSZMRZ3qS+yZi7V3yPc1hdepkGw333 lsebASrG8+KAMMbkoHLkmBA6emdO8oMGgFYo47JMtbW802d9u7+u/Bz7zZ67e9/FJN+b QYc2qjePyIMApw/4QgYsgJ8KcgEse9pTtDGaB3cGySl8545D3vOEsKpjVcKYOFo9ZPY3 5eMA== MIME-Version: 1.0 Received: by 10.50.161.232 with SMTP id xv8mr7600205igb.22.1353348936855; Mon, 19 Nov 2012 10:15:36 -0800 (PST) Received: by 10.64.135.39 with HTTP; Mon, 19 Nov 2012 10:15:36 -0800 (PST) In-Reply-To: <20121119175536.GM27306@merlins.org> References: <20121117234437.GA5542@merlins.org> <20121119175536.GM27306@merlins.org> Date: Mon, 19 Nov 2012 19:15:36 +0100 Message-ID: From: Dave Taht To: Marc MERLIN Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: cerowrt-users@lists.bufferbloat.net Subject: Re: [Cerowrt-users] Setting up bridging and debugging problems with LAN ports with WNDR3800 X-BeenThere: cerowrt-users@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Support for user problems regarding cerowrt List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 18:15:37 -0000 On Mon, Nov 19, 2012 at 6:55 PM, Marc MERLIN 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 s= ome >> 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 workin= g if I >> recall correcly, but it seems that cerowrt can't (the WAN port is ok, an= d 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 furthe= r > finding that unchecking the GUI option didn't clean the config file enoug= h > 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 =3D 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 exam= ple. 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 c= ooking > Home page: http://marc.merlins.org/ > _______________________________________________ > Cerowrt-users mailing list > Cerowrt-users@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-users --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html