Re: [Cerowrt-devel] CeroWrt 3.6.11-2 is out with ipv6-support package, bleeding edge dnsmasq, upnp,

Re: [Cerowrt-devel] CeroWrt 3.6.11-2 is out with ipv6-support package, bleeding edge dnsmasq, upnp,

[Richard Brown]

[-- Attachment #1.1: Type: text/plain, Size: 8063 bytes --]

Initial Impressions - Field Report on 3.6.11-2 Modena build

Dave: Congratulations on the new build. There's a lot to like here. I have a bunch of fussy comments...

- Installed without incident using procedure in the wiki
- DNS came up quickly (shortly after I had an IPv4 address)
- I didn't get DHCP address on Ethernet (se00) until I disconnected the Ethernet connector and re-connected it. I had disabled WiFi on my laptop, and used the ethernet link to burn the firmware (using address 192.168.1.2 as suggested in the wiki). After the tftp completed, I switched back to DHCP addressing, and waited for the router to come up. A couple minutes later, I still had a link local address (169.254…). I disconnected Ethernet and reconnected, and immediately got a 172.30.42.x address. Not sure what the proper behavior is, but I expected to have DHCP provide a 172.30.42.x address automatically.
- The web gui reports that the firmware is "CeroWrt Modena 3.6.10-3" (in two places), although the kernel is listed as "3.6.11" See attached screen shot.


[cid:29994FE1-5771-4593-88BD-41D1404C3842@home.lan]

- I have seen other reports about mDNS naming when I switch from the wired interface to using wireless. I get a GUI message in OSX that says, basically, 'Name Conflict: Updated Local Hostname from "Richs-MacBook-Pro-9.local" to "Richs-MacBook-Pro-10.local"' Here are the system log file entries that contain "mdns" at the time. NB: I am using CeroWrt as a secondary router, letting the gw00 interface connect to the LAN side of my primary router

---
12/25/12 9:58:30.349 PM mDNSResponderHelper[31716]: do_mDNSInterfaceAdvtIoctl: ioctl call SIOCGIFINFO_IN6 failed - error (22) Invalid argument
12/25/12 10:15:13.069 PM mDNSResponderHelper[32051]: do_mDNSInterfaceAdvtIoctl: ioctl call SIOCGIFINFO_IN6 failed - error (22) Invalid argument
12/25/12 10:15:13.069 PM mDNSResponderHelper[32051]: do_mDNSInterfaceAdvtIoctl: ioctl call SIOCGIFINFO_IN6 failed - error (22) Invalid argument
12/25/12 10:15:20.782 PM mDNSResponderHelper[32051]: do_mDNSInterfaceAdvtIoctl: ioctl call SIOCGIFINFO_IN6 failed - error (22) Invalid argument
12/25/12 10:15:20.783 PM mDNSResponderHelper[32051]: do_mDNSInterfaceAdvtIoctl: ioctl call SIOCGIFINFO_IN6 failed - error (22) Invalid argument
12/25/12 10:15:24.981 PM mDNSResponder[51]: mDNSCoreReceiveResponse: Received from FDBD:E109:C5B4:0004:0000:0000:0000:0001:5353    4 Richs-MacBook-Pro-9.local. Addr 172.30.42.25
12/25/12 10:15:24.981 PM mDNSResponder[51]: mDNSCoreReceiveResponse: ProbeCount 2; will deregister   16 Richs-MacBook-Pro-9.local. AAAA FE80:0000:0000:0000:E2F8:47FF:FE11:C796
12/25/12 10:15:24.982 PM mDNSResponder[51]: Local Hostname Richs-MacBook-Pro-9.local already in use; will try Richs-MacBook-Pro-10.local instead
12/25/12 10:15:24.982 PM mDNSResponder[51]: mDNSCoreReceiveResponse: Ignoring response received before we even began probing:   34 Richs-MacBook-Pro-9\.local._intermapper._tcp.local. SRV 0 0 8181 Richs-MacBook-Pro-10.local.
12/25/12 10:15:24.982 PM mDNSResponder[51]: mDNSCoreReceiveResponse: Ignoring response received before we even began probing:   34 PasswordWallet4\032Sync\032(CBC6BE41-B4A5-41AB-82C0-979B7119E187)._passwordwallet._tcp.local. SRV 0 0 1025 Richs-MacBook-Pro-10.local.
12/25/12 10:15:24.983 PM mDNSResponder[51]: mDNSCoreReceiveResponse: Ignoring response received before we even began probing:   34 Rich’s\032MacBook\032Pro\032(richb)._syncmate._tcp.local. SRV 0 0 27384 Richs-MacBook-Pro-10.local.
12/25/12 10:15:25.011 PM mDNSResponder[51]: mDNSCoreReceiveResponse: Ignoring response received before we even began probing:   34 Richs-MacBook-Pro-9\.local._intermapper._tcp.local. SRV 0 0 8181 Richs-MacBook-Pro-10.local.
12/25/12 10:15:25.012 PM mDNSResponder[51]: mDNSCoreReceiveResponse: Ignoring response received before we even began probing:   34 PasswordWallet4\032Sync\032(CBC6BE41-B4A5-41AB-82C0-979B7119E187)._passwordwallet._tcp.local. SRV 0 0 1025 Richs-MacBook-Pro-10.local.
12/25/12 10:15:25.012 PM mDNSResponder[51]: mDNSCoreReceiveResponse: Ignoring response received before we even began probing:   34 Rich’s\032MacBook\032Pro\032(richb)._syncmate._tcp.local. SRV 0 0 27384 Richs-MacBook-Pro-10.local.
12/25/12 10:15:25.904 PM mDNSResponder[51]: mDNSCoreReceiveResponse: Received from 172.30.42.97:5353   33 Richs-MacBook-Pro-9\.local._intermapper._tcp.local. SRV 0 0 8181 Richs-MacBook-Pro-9.local.
12/25/12 10:15:25.904 PM mDNSResponder[51]: mDNSCoreReceiveResponse: ProbeCount 0; will deregister   34 Richs-MacBook-Pro-9\.local._intermapper._tcp.local. SRV 0 0 8181 Richs-MacBook-Pro-10.local.
12/25/12 10:15:25.904 PM mDNSResponder[51]: mDNSCoreReceiveResponse: Received from 172.30.42.97:5353   33 PasswordWallet4\032Sync\032(CBC6BE41-B4A5-41AB-82C0-979B7119E187)._passwordwallet._tcp.local. SRV 0 0 1025 Richs-MacBook-Pro-9.local.
12/25/12 10:15:25.904 PM mDNSResponder[51]: mDNSCoreReceiveResponse: ProbeCount 0; will deregister   34 PasswordWallet4\032Sync\032(CBC6BE41-B4A5-41AB-82C0-979B7119E187)._passwordwallet._tcp.local. SRV 0 0 1025 Richs-MacBook-Pro-10.local.
12/25/12 10:15:25.905 PM mDNSResponder[51]: mDNSCoreReceiveResponse: Received from 172.30.42.97:5353   33 Rich’s\032MacBook\032Pro\032(richb)._syncmate._tcp.local. SRV 0 0 27384 Richs-MacBook-Pro-9.local.
12/25/12 10:15:25.905 PM mDNSResponder[51]: mDNSCoreReceiveResponse: ProbeCount 0; will deregister   34 Rich’s\032MacBook\032Pro\032(richb)._syncmate._tcp.local. SRV 0 0 27384 Richs-MacBook-Pro-10.local.
12/25/12 10:15:26.438 PM mDNSResponderHelper[32051]: do_mDNSInterfaceAdvtIoctl: ioctl call SIOCGIFINFO_IN6 failed - error (22) Invalid argument
12/25/12 10:15:26.438 PM mDNSResponderHelper[32051]: do_mDNSInterfaceAdvtIoctl: ioctl call SIOCGIFINFO_IN6 failed - error (22) Invalid argument
12/25/12 10:15:26.695 PM mDNSResponder[51]: Name Conflict: Updated Local Hostname from "Richs-MacBook-Pro-9.local" to "Richs-MacBook-Pro-10.local"
---

- The UPNP configuration page gives an error. See attached image.

---
This page contains the following errors:
error on line 111 at column 33: xmlParseEntityRef: no name
Below is a rendering of the page up to the first error.
---

[cid:BA5C8F54-C3FB-449E-A371-9F82E3A4CBEF@home.lan]

- IPv6: Without doing any configuration (and no external IPv6 addressing set up yet), my Mac reports an IPv6 of fdbd:e109:c5b4::3e07:54ff:fe3f:daff at the same time I got the DHCP address.
- I configured a Hurricane Electric tunnel using the GUI and the information from my tunnelbroker.net<http://tunnelbroker.net> page. CeroWrt successfully got the expected 2001:470… IPv6 address and could ping V6 hosts. None of the LAN interfaces of CeroWrt got a 2001… addresses, although they had fe80:... and fdbd:… addresses. For example, ifconfig showed:

...
se00      Link encap:Ethernet  HWaddr C6:3D:C7:9D:E3:9A
          inet addr:172.30.42.1  Bcast:172.30.42.31  Mask:255.255.255.224
          inet6 addr: fdbd:e109:c5b4::1/64 Scope:Global
          inet6 addr: fe80::c43d:c7ff:fe9d:e39a/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:16854 errors:0 dropped:0 overruns:12 frame:0
          TX packets:16612 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:4969550 (4.7 MiB)  TX bytes:7208592 (6.8 MiB)
          Interrupt:4

sw00      Link encap:Ethernet  HWaddr C4:3D:C7:9D:E3:9A
          inet addr:172.30.42.65  Bcast:172.30.42.95  Mask:255.255.255.224
          inet6 addr: fdbd:e109:c5b4:2::1/64 Scope:Global
          inet6 addr: fe80::c63d:c7ff:fe9d:e39a/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:456 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:32
          RX bytes:0 (0.0 B)  TX bytes:138408 (135.1 KiB)
… etc...

I will keep playing with IPv6 configuration following the OpenWrt ipv6-support wiki page…

Rich

[-- Attachment #1.2: Type: text/html, Size: 10254 bytes --]

[-- Attachment #2: CeroWrt-3.6.11-2.png --]
[-- Type: image/png, Size: 27182 bytes --]

[-- Attachment #3: CeroWrt 3.6.11-2-UPNP error.png --]
[-- Type: image/png, Size: 22574 bytes --]

Re: [Cerowrt-devel] CeroWrt 3.6.11-2 is out with ipv6-support package, bleeding edge dnsmasq, upnp,

[Dave Taht]

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

As for the MDNS issue, we've filed a bug on it, and demonstrated to
multiple people "that should know", and no progress on fixing it as yet.

I hope it's merely a bug in avahi rather than the protocol. It's a real
PITA.

-- 
Dave Täht

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

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

Re: [Cerowrt-devel] CeroWrt 3.6.11-2 is out with ipv6-support package, bleeding edge dnsmasq, upnp,

[Dave Taht]

I note that the bufferbloat.net domain filters out ip addresses in
message bodies, so richard's original message probably didn't make the
list. I have to find a fix for that - so 172 dot X dot Y dot Z goes
through.

...

Thx for the complete report!

Configuration name problem noted and fixed. (hopefully). Have to automate
that, I keep doing it...

An update to the luci upnp gui landed a day or two ago for upnp, it's my
hope that addresses the bug there, but as I am still 3000 miles away from
the nearest router I dare reflash I won't be in a position to test til
saturday. I did do a build with that fix in it:

http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.6.11-3/

Which is so trivial as you can do a sysupgrade to it without harming your
existing config. Unless I broke something else.

The default configuration defaults to generating ULAs which are local ipv6
addresses in the fd:: range. While this is useful for bringing up a ipv6
network, it's not so useful for connecting to the outside world with it, as
you've discovered. My hope is with the linux 3.7 release to be able to
enable npt66 by default in this case, (which was the source of some
controversy earlier this month), but using 3.7 as a base is a bit of a long
way out. I'm trying to get on top of the 3.7 issue (and some other gui
stuff) by doing an x86 virtual build (which so far, doesn't boot)

As for not distributing the 2001:: (and disabling the ula entirely) I don't
know - that package is so bleeding edge as yet! Happy hacking.




-- 
Dave Täht

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

Re: [Cerowrt-devel] CeroWrt 3.6.11-3

[Richard Brown]

Update on 3.6.11-3:

- re: Firmware version. The web GUI now says, "CeroWrt Modena 3.6.11-3" - So this is fixed.

- re: the DHCP address after initial firmware install. Patience, grasshopper… The Flashing Instructions in the wiki say to wait at least 5 minutes after the tftp completes. I waited six minutes, and it got a 172.30.42.x address as desired. 

- I'm still planning to play with IPv6.

Rich Brown
Hanover, NH

Re: [Cerowrt-devel] CeroWrt 3.6.11-3

[Chris Lawrence]

The UPnP problem is a simple mistake: the LuCI interface is strict
XML, and the upnp code uses a bare ampersand without XML escapes.  To
fix:

edit /usr/lib/lua/luci/model/cbi/upnp/upnp.lua, line 16, replacing the
'&' character in "Universal Plug & Play" with 'and'

For ipv6 (using 6to4), I followed the instructions here and got things to work:
http://wiki.openwrt.org/doc/uci/network6.  In my case, all I needed to
do was add 2 lines to /etc/config/network6, after adding a 6to4
interface called "ipv6" through LuCI:

config interface 'ipv6'
    option mode '6to4'

Unlike before there doesn't seem to be an option to specify where to
start the subnet numbering (and the old setting in /etc/config/network
is ignored), but it works fine regardless.

Thanks Dave!


Chris

On Wed, Dec 26, 2012 at 4:19 PM, Richard Brown
<richard.e.brown@dartware.com> wrote:
> Update on 3.6.11-3:
>
> - re: Firmware version. The web GUI now says, "CeroWrt Modena 3.6.11-3" - So this is fixed.
>
> - re: the DHCP address after initial firmware install. Patience, grasshopper… The Flashing Instructions in the wiki say to wait at least 5 minutes after the tftp completes. I waited six minutes, and it got a 172.30.42.x address as desired.
>
> - I'm still planning to play with IPv6.
>
> Rich Brown
> Hanover, NH
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 
Chris Lawrence <lordsutch@gmail.com>

Website: http://www.cnlawrence.com/