Really? No interest in this at all? Not even enough to trial it to see if it's useful?
On 5/29/11 10:34 AM, Philip Prindeville wrote: > I've been thinking about a couple of projects that I'd like to add (below) to > OpenWRT, but that I don't always have the subject matter expertise to either > configure or test them... but I do know how to do scripting, manage > configurations with UCI, etc. > > What would be useful for me would be a way to list a project or feature on > the Wiki that I'm willing to work with, and to solicit a partner to > collaborate with. It's sometimes the case that programmers aren't "power > admins" of certain features, and the people that understand those features > don't always know all the subtleties of building OpenWRT support in for them. > > So this would be a means for someone to say, "Hey, I want to work on X, and I > can do the scripting, but I'm not exactly clear on all of the configuration > details" (for example), and someone with the competence and time and > motivation could reply. > > Does this seem reasonable? > > For my part, I'm interested in the following two projects for now: > > (1) Add IPsec road-warrior capability to OpenWRT, so that (a) we could use > certificate-based authentication for the mobile clients (which might include > smartphones), and (b) if we had 192.168.1.0/24 as the LAN subnet for OpenWRT > (as we often do), a "pool" of /32 addresses could be carved out from that, > say 192.168.1.241-192.168.1.254 which the router would then Proxy-ARP for > (making hosts on the LAN network believe that the IPsec clients were > adjacent, which is useful for a whole lot of things... including DirecTV > media sharing, etc). > > Anyway, as I said, I could do the scripting, but some of the Ipsec-tools (or > Strongswan) stuff I'm a little unfamiliar with, like how to use openssl to > generate self-signed certificate authorities, etc. > > (2) Add NAT hooks to Freeswitch and Asterisk so that when either brokers an > incoming phone call's SIP path, it uses ipt to automatically set up (and > later, tear down) a NAT hole for the call, so that the phones themselves > don't have to be configured explicitly for NAT (and even when you get it > right, have of the phones out there don't seem to handle NAT correctly in all > cases anyway). > > So in this case, I could add the NAT hooks to SIP signaling for Asterisk and > walk the fix through upstream, but I'm a little rusty on some of the > signaling corner cases (like re-INVITEs, for example) or how to best test for > all of the scenarios. > > Thanks, > > -Philip _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
