On 3/10/2010 1:04 PM, kb9khm wrote:
> This is where I think the Icom implementation added an unnecessary
> feature. D-STAR protocol has its own useable address space in the
> callsign fields of the header. In DV mode there is no reason to
> assign a callsign an IP address (nor in DD mode either, really).
I whole-heartedly, absolutely, 100% agree with this. Dump the IP
address junk from D-STAR.
Nah, just fix it so it behaves like a properly working private LAN for
the ID-1 Ethernet users.
"Dropping the IP stuff" isn't really an option for the ID-1 users.
There needs to be a working system to replace it before ripping it out
of user-registration. But 100% agreed, it shouldn't be there. It
should be automated with DHCP and Dynamic DNS. The software to do that
is ALREADY THERE on the Gateway machine...
a) All D-STAR DD Gateways act as local DHCP servers and hand out an IP
address to whatever gets plugged into an ID-1.
b) Tunneling works perfectly between all DD users by IP, and knows how
to route automatically between sites if you were last heard on a
particular Gateway. (Does this already work? I don't think it does, but
don't know.)
c) DNS is handled dynamically and registered with a properly configured
local DHCP server and a properly synchronized private DNS zone. The DNS
server IP that would be handed out over the above-mentioned DHCP would
make it so you could reach ANY D-STAR ID-1's Ethernet port connected IP
device(s) by a standardized naming convention...
"wy0x-00_0C_FF_FF_FF_FF.dstar-private.local" or whatever the heck you
want to call the zone.
(Bear with me here, I know a callsign+MAC address DNS address is damn
long, but you need it, because you need to make sure it's set up to
handle multiple machines connected to the Ethernet behind a single ID-1.)
d) Users do NOT need to be registered to participate in this. DHCP
request = Done.
e) Users could log into the centralized webserver somewhere, and request
a CNAME record for a particular callsign-mac combo...
"coloradoareas.dstar-private.local" CNAME to
"wy0x-00_0C_FF_FF_FF_FF.dstar-private.local".
To me, this kinda looks like what they were TRYING to do, but
implemented it all wrong. What Icom did instead was turn the callsign
itself into a HASH that creates the IP address. That forgets completely
that you could plug three laptops into a hub/switch and then plug that
into the ID-1. You'd think the Icom engineers would know how Ethernet
works, by now...
Anyway... to the end users the above would look like this, from a useage
standpoint.
- Set your ID-1 properly to that funky Data mode setting.
- Plug in ANYTHING behind the ID-1.
- Device requests and IP and gets it.
- Want to route to your buddy's machine in another state? Ask him for
his callsign and MAC address of the machine you want to talk to.
- Want to make it easier? Request a CNAME (alias for those who don't
"speak DNS") that's something easy to remember to point to that other
more accurate technical DNS name. Tell your buddy, "I registered
wy0x-home.dstar-private.local" for you. You can just connect to that.
Other things that probably need to be done...
All web and other traffic leaving/entering the Amateur network from the
Internet should have been put through a Squid or other proxy server.
Two reasons... performance (caching) and FILTERS.
Things to filter or at least give the admin the ability to filter:
Words that will get you fined by the FCC if you put them over the
Amateur band here in the U.S. for example), and the proxy should also
block all https:// connections in countries where encryption is illegal,
etc. Also the ability to block ports in/out (iptables), perhaps even
build static NATs for servers that "exist" both on D-STAR and the public
Net... etc.
Anyway... there's my wishlist Utopian design doc before an ID-1 would
even be useful to me... and it would also make the ID-1 super-simple for
most folks who just want to "plug and play" to do it.
Maybe folks have better ideas... but that'd work for just about
everyone... in DD mode.
Nate WY0X
