From: Dave Taht <dave.taht@gmail.com>
To: Maciej Soltysiak <maciej@soltysiak.com>
Cc: "cerowrt-devel@lists.bufferbloat.net"
<cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] upnpd problem semi-solved
Date: Thu, 30 Jan 2014 07:06:01 -0800 [thread overview]
Message-ID: <CAA93jw5-pe6yvdNZcLh4pVJqp8=FvFC8b=BfHFoAmqCnqYuc_Q@mail.gmail.com> (raw)
In-Reply-To: <CAMZR1YC2d9bg=JqiHOUaws54dFkV1QKh43eSYNXTkLiBxwt-uw@mail.gmail.com>
I have been gradually realizing that solving all the problems highly
dynamically assigned native
ipv6 brings us is not going to get solved this week, or this year.
anyway, I am still working on stablizing comcast specific stuff here:
http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/comcast/3.10.28-4/
but since tunnels don't go boom it's more suitable for general use...
improvements since the last time I talked about anything:
+ rngd, polipo, ahcpd, pimd, both web servers, - moved to procd
+ upnpd updated and at least partially fixed
+ babeld logs to /dev/null
hopefully this should stop running out of memory and flash.
+ tunnelling headaches sorta solved
we no longer spin out of control when establishing an he tunnel
while a native ipv6 session is active
- tunneling headaches
but a ton of things don't work either, like dns
advise: tunnel or run native, not both
turn off sourcerouting for tunnels (as yet)
- ipv6 dynamic headaches
poor integration with ahcp, dhcp-pd, etc
(and I only get a /60 from comcast)
(and a reboot of the router led to getting new addresses
assigned and caused chaos through my ahcpd'd
and dhcp-pd'd testbed)
- a source of unaligned instruction traps found but not fixed
https://dev.openwrt.org/ticket/14868
The trap occurs during the call to SyS_prlimit64.
Didn't see anything obvious that said "I'm
possibly unaligned, fixme"
- package signing broke a few releases back
disabled here. ENOTIME.
- babeld not moved to procd
- babeld fails to detect a channel on AP wireless interfaces.
- haven't necessarily got all the ucitrack dependencies right overall
- still no mosh on the router...
in other news, ipv6 support has landed for mosh, upstream
dropbear is adding support for TOS setting, and
I actually saw dnsmasq doing dnssec validation without crashing (on x86).
I am overjoyed to finally have ipv6 support for mosh upstream. Now I
can finally go e2e with it and leave a ton of connections nailed up.
https://github.com/keithw/mosh
note: ipv6 support requires a newer perl library than the previous generation of
mosh, libio-socket-ip-perl.
On Wed, Jan 29, 2014 at 11:54 AM, Maciej Soltysiak <maciej@soltysiak.com> wrote:
> DLNA discovery is using SSDP. SSDP are multicasts which don't easily
> traverse between interfaces.
> minissdp is supposed to proxy between interfaces. I think it also
> keeps track of the devices so it can respond on behalf of other
> devices.
>
> I'm running 3.10.18-1. If there's a build you would suggest I try, I'm
> happy to do it.
>
>
> On Wed, Jan 29, 2014 at 7:19 PM, Dave Taht <dave.taht@gmail.com> wrote:
>> Well, I see ipv6 support in the current codebase, don't know if it's
>> in the codebase I'm trying now...
>>
>> my understanding of the separate minissdp server was that it acted as
>> an arbitrator between
>> multiple possible users of the functionality (like dlna)
>>
>> On Wed, Jan 29, 2014 at 9:25 AM, Paul Handly <paul@hand.ly> wrote:
>>> SSDP registration (server) and subsequent discovery (client) across
>>> subnets was what I needed minissdpd for, but the devices I was trying to
>>> drive (Sonos) are kind of pricey as a test case.
>>>
>>> Having an IPv6 address on the listen interface/s broke the old build of
>>> minissdpd, so I had to choose between IPv6 and Sonos.
>>>
>>> --
>>> Paul Handly <paul@hand.ly>
>>>
>>> On Wed, Jan 29, 2014, at 11:55, Dave Taht wrote:
>>>> The version I was carrying in ceropackages was obsolete and didn't
>>>> integrate
>>>> into fw3. Dropped that release, built from openwrt head, I can open ports
>>>> now
>>>> from the transmission bittorrent client and from dns-sd (on macos) now.
>>>>
>>>> the author tells me the latest version (not what I built, it's only a
>>>> few days old) does PCP also.
>>>>
>>>> 1) It's not clear to me why minissdpd was needed?
>>>>
>>>> 2) Are there any other test cases I could try?
>>>>
>>>> --
>>>> 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
>>
>>
>>
>> --
>> 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
--
Dave Täht
Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
prev parent reply other threads:[~2014-01-30 15:06 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-29 16:55 Dave Taht
2014-01-29 17:25 ` Paul Handly
2014-01-29 18:19 ` Dave Taht
2014-01-29 19:54 ` Maciej Soltysiak
2014-01-30 15:06 ` Dave Taht [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAA93jw5-pe6yvdNZcLh4pVJqp8=FvFC8b=BfHFoAmqCnqYuc_Q@mail.gmail.com' \
--to=dave.taht@gmail.com \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=maciej@soltysiak.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox