I don't which "tomorrow" you mean (given the time on your message), but I will be unavailable today (Saturday) until about 2:30pm. Note that I occasionally "/system reset-configuration" on my radio (for testing/learning purposes), so I'd like to save whatever you do (or what you tell me to do) to a file. I know there's a "save configuration" option, so I suppose I can use that. Anyway, I'd like to *LEARN* what you are doing (that being one of the points of this exercise). -- Dean AE7Q 425-359-4276 (cell) On 2014-03-22 00:31, Bart Kus wrote:

Yeah, I think it'd be good to do this tomorrow. I can setup Paine-S2 to run BGP to you, configure your modem to reciprocate, setup IPsec(AH), get your static (/32?) routing via your modem and you can distribute it internally however you like. I can also add a DNS entry for that IP as you require.

Gotta flip some SQL triggers to SQL stored procs, which I've been meaning to do for weeks now.

--Bart

On 3/21/2014 11:09 PM, Tom Hayward wrote:

...

On Fri, Mar 21, 2014 at 8:40 PM, Dean Gibson AE7Q <hamwan@ae7q.net> wrote:

...

Now that I have an IP address (albeit DHCP) on HamWAN, how do I assign an ampr.org DNS hostname to it, and (if feasible) a reverse IP DNS entry? Do I:

1. Contact someone here? 2. Contact John Hays (the owner of 44.24.0.0/16)? 3. Need a fixed IP address for these features?

Dean,

This is a really good question. DNS is an essential service for a network. It makes higher-level services much more useful (who wants to memorize IP addresses? Okay... other than me!). HamWAN plans to let you create *.hamwan.net hostnames. At the moment, the DNS servers are running (redundant, at multiple sites), but there's no user interface for people like you to add entries. Only a few records have been manually entered.

For reverse DNS, Brian Kantor needs to configure the AMPR DNS servers to delegate HamWAN's subnet to HamWAN's DNS servers. He hasn't figured out a way to integrate this into his DNS system yet.

Okay, finally an answer to your question: *.ampr.org hostnames must be assigned via AMPR's email robot. Your email address will need to be in the whitelist for this to work. I think this boils down to asking John Hays to add the record for you.

It's probably best to work with Bart to get a static IP address(es) first. In a previous email, I think he asked you if you'd like to experiment with static address assignment. I suspect this will involve BGP, so your subnet will roam with you to whatever HamWAN node you connect to.

Tom KD7LXL

On Mar 22, 2014 9:09 AM, "Kenny Richards" <richark@gmail.com> wrote:

Maybe the 'what Bart does' could be also posted to the HamWAN wiki? ;-)

73, Kenny

The process is: 1. Design 2. Implement 3. Test 4. Publish Right now we're trying to start step 2. If everything works as intended, it will be published to the wiki (most likely in the form of an edit to the client configuration page). Ideally the sector configuration will be published, too, so that other regions can try it. Tom KD7LXL

On 3/30/2014 1:56 AM, Dean Gibson AE7Q wrote:

On 2014-03-21 23:09, Tom Hayward wrote:

...

On Fri, Mar 21, 2014 at 8:40 PM, Dean Gibson AE7Q<hamwan@ae7q.net> wrote:

...

... Dean,

This is a really good question. DNS is an essential service for a network. It makes higher-level services much more useful (who wants to memorize IP addresses? Okay... other than me!). HamWAN plans to let you create *.hamwan.net hostnames. At the moment, the DNS servers are running (redundant, at multiple sites), but there's no user interface for people like you to add entries. Only a few records have been manually entered.

You have a user interface. If you are running ISC's BIND version 9, in your master "named.conf" file, add the following clause to the "zone" statement for "hamwan.net": update-policy { };

Then, once for each user, you just need to do (substitute the user's callsign for /*ae7q*/):

1. On a Linux system, run: dnssec-keygen -a HMAC-MD5 -b 128 -n HOST /*ae7q*/ 2. Send the user a copy of the "K/*ae7q*/.+157.#####.key" file. The user will use the key value in the radio's "/tool dns-update ..." command (or equivalently, the Linux "nsupdate" command) whenever the IP address needs to be updated. You'll need to tell the user the IP address of the master DNS server (probably a.ns.hamwan.net = 44.24.244.2, unless your A and B DNS servers are slaves to a hidden master). 3. In your master "named.conf" file, add the following line, using the key value from the above file: key "/*ae7q*/" {algorithm hmac-md5; secret "/key value.../"; }; 4. In your master "named.conf" file, in the zone statement for "hamwan.net", insert the following into the "update-policy" clause: grant "/*ae7q*/" subdomain "/*ae7q*/.hamwan.net"; 5. Reload BIND (named). On CentOS: service named reload

This way, users will only be able to create/update DNS records of the form "anything.<only-their-callsign>.hamwan.net".

-- Dean

ps: I've tested this on my own DNS servers. It's much better than using the zone "allow-update" clause, because the latter applies to a whole zone (which would mean creating a new zone for each user ...).

Hi Dean, Thanks for outlining that approach. I have a few questions: 1. Where is the protocol for zone updating documented? I see RFC 2136, but I don't see where it uses authentication anywhere. How does the authentication work here? 2. Is the authentication Part97 compatible? 3. Once an update session is authenticated, are there any further provisions for integrity checking during the (I assume) TCP? Are there HMACs sent along with it, or one giant signature at the bottom? I don't think we'll be able to use this approach for a few reasons: 1. It seems to rely on a shared secret. We have a goal of being fully autonomous with no degradation in network services when all other means of communication are down. Passing shared secrets around securely under Part 97 is impossible as far as I can tell. They need to be "encoded for the purposes of obscuring their meaning" -- the exact thing the FCC forbids, in order for them to remain secrets. Asymmetric cryptography is our only option, and only when it's used as an integrity or identity mechanism. Because of all this, we actively avoid any pre-shared-key (PSK) or password-based systems in our designs. 2. Even though you can update one server by talking to DNS directly, how does that change get to all the others? 1. People update every single server explicitly? That's a PITA, and when servers are down, they'll miss updates. I wouldn't expect people to keep a retry queue on their own. When servers are decommissioned/brought up this would mean pushing a list of servers to users constantly. More PITA. 2. You rightly mentioned we could do a master server, but this introduces a single point of failure. Another design goal of HamWAN is to be as fault-tolerant as possible. A single special server contradicts that goal when that site goes offline. Yes, you can anycast the special server's IP, but then you'd have an impossible (read: unsupported) zone-update topology between the DNS servers. 3. This introduces yet-another piece of cryptographic identity for people to keep secure. I'd like to avoid adding complexity when it comes to identity. I'd like it all to boil down to your private key for your PKI key pair. 4. DNS is not the only piece of configuration people will need to send to HamWAN when they want changes. Edge firewall rules are another good example. I'm sure tons of others will follow. For simplicity's sake, I'd like to unify it all under a single configuration management system. 5. We don't use BIND. I've run it professionally and at scale for enough years to have learned to avoid it. We use PowerDNS for our authoritative DNS service, and Unbound for our recursive DNS service. Even though PowerDNS will likely have equivalent utilities/configuration options as you mentioned for BIND above, the other problems remain. So, what ARE we doing here? We've chosen to keep the data which feeds PowerDNS in a PostgreSQL database. This shifts the problem of updates and replication into the database realm. The presence of said database also provides us a fairly universal and highly adaptable place to keep all other configuration and state information. The problem is now reduced to just allowing users secure and Part97 compatible access to PostgreSQL. That problem is solved by PostgreSQL's support for certificate-based authentication of users. We have not yet verified if the sessions PostgreSQL provides also provide HMAC support after the identity is established, while avoiding encryption. If that's possible, then great, we're done. If not, we can do some further work to make that happen. This still leaves the problem of how to avoid a single-master single point of failure scenario. Luckily, we've figured out how to turn PostgreSQL into a true multi-master (that means write-anywhere) database by the use of a piece of software called SymmetricDS. There's nothing particularly magical about this software, I'm sure we could implement an equivalent in-house, but why bother when someone else has already done it! East PostgreSQL server listens on a pair of anycast IPs, which are pointed to by a single DNS record. No user configuration or re-routing required when database servers or network links go down! So at the end of the day, we've got a fully redundant multi-master database, that is modifiable by users using Part97 compatible protocols, using their single identity to keep things simple, available via a single DNS name and pair of anycast IPs, which happens to have authoritative DNS as one of the configuration items it stores. This is absolutely foundational to our future success in other services. Now for the big fat disclaimer. I've been extremely busy lately, and the reality of what's actually up and running is: a single instance of PowerDNS, a single instance of PostgreSQL, and no instances of SymmetricDS. We haven't verified the user access protocol. Right now we're at the stage of flipping some triggers into stored procedures, since a design mistake was made with the schema. We may or may not write some middleware to sit in front of the database and terminate the user sessions, I just don't know yet. While custom software that's Part97 compatible is do-able, and we can release multi-platform solutions for simple command-line configuration management, the web aspect of things is harder. There is an open problem around how do we use existing web browsers in such a way that's Part97 compatible and yet authenticated and integrity enforced. HTTPS with null cipher used to be an option, but all the browsers decided to "improve" their software and removed null cipher support. The one thing on the horizon that looks promising is WebCryptoAPI, which could allow for JavaScript to HMAC all requests using the installed private keys, without having direct access to the private keys. The Authentication <https://www.hamwan.org/t/tiki-index.php?page=Authentication&structure=HamWAN> page lists all the solutions we've brainstormed to date. Feel free to address this problem space too. --Bart

On 3/30/2014 5:42 PM, Dean Gibson AE7Q wrote:

Responses inline, bolded in blue:

On 2014-03-30 12:38, Bart Kus wrote:

...

Hi Dean,

Thanks for outlining that approach. I have a few questions:

1. Where is the protocol for zone updating documented? I see RFC 2136, but I don't see where it uses authentication anywhere. How does the authentication work here? *DDNS uses "TSIG": http://en.wikipedia.org/wiki/TSIG* 2. Is the authentication Part97 compatible? *Not sure (see below); it's a signature process using hashing.* 3. Once an update session is authenticated, are there any further provisions for integrity checking during the (I assume) TCP? Are there HMACs sent along with it, or one giant signature at the bottom? *I'm sure the details are in the above link and its references.*

Thanks! It does indeed look like TSIG is P97-compatible. Good to know, we may use it as some point.

...

1.

I don't think we'll be able to use this approach for a few reasons:

1. It seems to rely on a shared secret. *Yes.* We have a goal of being fully autonomous with no degradation in network services when all other means of communication are down. *Yes, that's the whole point of using multiple 44.x.x.x DNS servers.* Passing shared secrets around securely under Part 97 is impossible as far as I can tell. *I'm not sure I agree (see below).* They need to be "encoded for the purposes of obscuring their meaning" -- the exact thing the FCC forbids, in order for them to remain secrets. *There is no "meaning" other than "authenticate me" (see below).*

If you're referring to the use of TSIG as a signature at the end of a message, then yes, that hash is not encrypting any information, it's simply signing something as being legitimate. But when you're talking about getting a private key from point A to point B over the network, and encrypting it during transmission so that it's not visible to others, then I believe that's violating FCC regulations. That's what I mean when I say we can't use PSKs: because their dissemination is not compatible with P97, even though their application is.

...

1. Asymmetric cryptography is our only option, and only when it's used as an integrity or identity mechanism. *How does this apply to using SSH over the air, which WamWAN enables by the distribution of SSH keys on the Wiki? SSH not only authenticates, it encrypts >>>all<<< the traffic. *Because of all this, we actively avoid any pre-shared-key (PSK) or password-based systems in our designs. *From a legal perspective, I see that as a distinction without a difference.*

Yup, we're in a bad spot here. Presently trying to figure out how to enable SSH with authentication and integrity, but not encryption. There are other alternatives being considered such as IPsec(AH)+telnet, but they're far more gross than fixing SSH to be P97 compatible. The problem is there exists no protocol in the world that provides remote control over ham radio in a secure way that respects P97. Hams haven't yet done the work to invent one. We're trying.

...

1.

2. Even though you can update one server by talking to DNS directly, how does that change get to all the others? *That's a fundamental feature of BIND. **Historically, the slaves query periodically (on the interval specified in the SOA record). However, more recent (like the last decade) versions of BIND have the master push updates to the slaves. This is true when changes are made, whether or not DDNS is used. The updates happen pretty quickly (within a couple minutes).*

It was a rhetorical question to setup the answers in the indented list below. :)

...

1.

1. People update every single server explicitly? *No; see above.* That's a PITA, and when servers are down, they'll miss updates. I wouldn't expect people to keep a retry queue on their own. When servers are decommissioned/brought up this would mean pushing a list of servers to users constantly. *Not with BIND. Somewhere in the 44.x.x.x world there needs to be a fixed IP (multiple) source of DNS info, just like the (13? or so) DNS root servers. I've replaced my "root servers" file once in ten years. Hopefully, things are not going to be so dynamic in HamWAN that hamwan.net DNS servers are going to be constantly on the move.* More PITA.

No need to worry about changes here. HamWAN authoritative DNS servers shall forever and always(*) be on 44.24.244.2 and 44.24.245.2. These are anycast IPs from 2 different anycast ranges. They're documented on the Core Routing <https://www.hamwan.org/t/tiki-index.php?page=Core+Routing&structure=HamWAN> page. A similar pair (.1) are allocated to recursive DNS service. These should also be global and present in other people's HamWAN instances in other states. A roaming client wouldn't need to change a thing when going from system to system. As we spin up Memphis and Michigan, we're helping those teams ensure seamless compatibility. * = OK, we might at some point use different IPs for unforeseeable reasons. Forever is a long time. But as far as the present design of this, there's no need to change those IPs in the face of any presently possible network changes.

...

1. You rightly mentioned we could do a master server, but this introduces a single point of failure. *There has to be one authoritative source in any system. *

Distributed peer systems do not have this property. It's time to shed those shackles and embrace a better tomorrow! A change can be submitted via any node in the peer cloud. There is no master or authority, other than the peer cloud itself. The challenge in such systems is how do you resolve conflicts. SymmetricDS provides a rich set of conflict resolution solutions. Also note that this means not all nodes will always agree on what the data should be at all times, but they will eventually come to a consensus. This is fine for DNS and many other systems, as it just introduces a delay while maintaining consistency in the long run.

...

1. *BIND slaves do not become inoperative just because the master goes down. For extended outages, it's pretty easy to swap masters.*

Regarding swapping masters, the less human involvement in the face of failure, the better. I automatically raise an eye when someone says "If X breaks, we'll login and do Y". That's a fragile design - one that relies on a human timely response. Right now we have "if a link breaks, OSPF will re-route the packets", which is a fine solution. Need more of that.

...

1. Another design goal of HamWAN is to be as fault-tolerant as possible. A single special server contradicts that goal when that site goes offline. *Again, BIND does ...* Yes, you can anycast the special server's IP, but then you'd have an impossible (read: unsupported) zone-update topology between the DNS servers. 1. This introduces yet-another piece of cryptographic identity for people to keep secure. I'd like to avoid adding complexity when it comes to identity. I'd like it all to boil down to your private key for your PKI key pair. *I don't understand the distinction. **A private key isn't conceptually different from other authentication schemes. You have secret files. I do agree it would be nice to only have one key.*

I wasn't making a distinction. It's just yet-another file to worry about keeping private. Added hassle. Bad.

...

1.

2. DNS is not the only piece of configuration people will need to send to HamWAN when they want changes. Edge firewall rules are another good example. I'm sure tons of others will follow. For simplicity's sake, I'd like to unify it all under a single configuration management system. 3. We don't use BIND. I've run it professionally and at scale for enough years to have learned to avoid it. *Well, I have more networked devices (64 distinct IP addresses as of this morning; all but six currently online) in my house than are presently on the HamWan network.*

Depends how you define "on the HamWAN network". :) We only keep track of modems, not the systems behind them. I've got something like 15 boxes here that are connected, not sure what others have.

...

1. * They are all using DHCP (two servers using failover) for the assignment of both static and dynamic IP addresses. The two DHCP servers update five internal DNS (BIND) servers. I don't think ***HamWAN * will have to worry about scalability in my remaining lifetime.*

The BIND choice isn't about scalability, it's about stability. I can take you through some awesome BIND failures I've seen over the years. Let's do that not-in-this-email though.

...

1. We use PowerDNS for our authoritative DNS service, and Unbound for our recursive DNS service. Even though PowerDNS will likely have equivalent utilities/configuration options as you mentioned for BIND above, the other problems remain.

So, what ARE we doing here? We've chosen to keep the data which feeds PowerDNS in a PostgreSQL database. This shifts the problem of updates and replication into the database realm. The presence of said database also provides us a fairly universal and highly adaptable place to keep all other configuration and state information. The problem is now reduced to just allowing users secure and Part97 compatible access to PostgreSQL. That problem is solved by PostgreSQL's support for certificate-based authentication of users. We have not yet verified if the sessions PostgreSQL provides also provide HMAC support after the identity is established, while avoiding encryption. If that's possible, then great, we're done. If not, we can do some further work to make that happen.

This still leaves the problem of how to avoid a single-master single point of failure scenario. Luckily, we've figured out how to turn PostgreSQL into a true multi-master (that means write-anywhere) database by the use of a piece of software called SymmetricDS. *[Idle comment: I use PostgreSQL 9.0 replication among four PostgreSQL servers, using "hot standby".]* There's nothing particularly magical about this software, I'm sure we could implement an equivalent in-house, but why bother when someone else has already done it! East PostgreSQL server listens on a pair of anycast IPs, which are pointed to by a single DNS record. No user configuration or re-routing required when database servers or network links go down!

So at the end of the day, we've got a fully redundant multi-master database, that is modifiable by users using Part97 compatible protocols, using their single identity to keep things simple, available via a single DNS name and pair of anycast IPs, which happens to have authoritative DNS as one of the configuration items it stores. This is absolutely foundational to our future success in other services.

Now for the big fat disclaimer. I've been extremely busy lately, and the reality of what's actually up and running is: a single instance of PowerDNS, a single instance of PostgreSQL, and no instances of SymmetricDS. We haven't verified the user access protocol. Right now we're at the stage of flipping some triggers into stored procedures, since a design mistake was made with the schema. We may or may not write some middleware to sit in front of the database and terminate the user sessions, I just don't know yet.

While custom software that's Part97 compatible is do-able, and we can release multi-platform solutions for simple command-line configuration management, the web aspect of things is harder. There is an open problem around how do we use existing web browsers in such a way that's Part97 compatible and yet authenticated and integrity enforced. HTTPS with null cipher used to be an option, but all the browsers decided to "improve" their software and removed null cipher support. The one thing on the horizon that looks promising is WebCryptoAPI, which could allow for JavaScript to HMAC all requests using the installed private keys, without having direct access to the private keys. The Authentication <https://www.hamwan.org/t/tiki-index.php?page=Authentication&structure=HamWAN> page lists all the solutions we've brainstormed to date. Feel free to address this problem space too.

--Bart

*In conclusion ...,* the issues here in my mind:

1. Encryption: FCC Part 97.113 prohibits /"... //messages encoded for the purpose of obscuring their meaning, except as otherwise provided herein ..."/. The exceptions have to do with *communication control* (model aircraft and spacecraft) and not message content. I would think the FCC would accept encryption as part of authentication (that's part of securely *controlling the communication*), but not message content.

As far as HMAC and identity hashes go, I agree.

1. In other words, what is the *intent of any obscuration*?

I'd also say that the output of a hash function when used as a message or identity signature is not obscured in any way. The signature is transmitted in plaintext over the air for anyone to inspect. The signature is the message, and it obscures nothing. In the case of HMAC, it signs the plaintext content preceding it right on the air. Truly everything is out in the open.

1. For example, SSH (commonly port 22) and HTTPS (commonly port 443) would be out, as would the equivalent secure eMail protocols (ports 993, 995, 465, etc...), as clear meanings in the *content* are obscured.

Yup, and hams need to get off their collective butts and fix this. There is no protocol known to me which allows hams to have secure control without also engaging encryption of the content.

1. There is no "meaning" in a secure signature key (other than "keep out"); the endpoints of the connection are visible. It's the remaining/attached content that matters. 2. Redundancy: I appreciate that goal. However, true redundancy requires either simplicity, or a long industry history that proves the complexity to be reliable. If nothing else, *the computer world is littered with complex solutions **that don't work (or work well).* I see the HamWAN design heading down that road.

Yeah, but I aspire to provide the best solutions I can. I've got no interest in releasing half-assed designs. Anyone can do that and it doesn't advance anything. Complexity does not equal failure or unusability. It's all about wrapping all the complexity into a simple user experience in the end. Cars are incredibly complicated things, but they boil down to a wheel and some pedals for the end user. Right now HamWAN is at the stage of assembling engines in the factory. There's a lot of engineering work to go around. To help users cope with all the changes and exposed complexity happening right now, we're suggesting the shared administration model. Since you chose not to participate in that, you need to keep up on your own. I would also point out that you allow Comcast or whoever your ISP is to manage your modem, since they don't even give you a choice. Could you imagine what Comcast would have to deal with if they had to call up every user to do something on their end every time they changed DOCSIS channels on the network?

1. Meanwhile, we have some simple "wants" (not "needs") that aren't being addressed, due to a future "perfect" solution. I would much rather adopt a scheme that works, and then improve it later as needed.

What do you want/need right now? If it's DNS entries, we can do that by hand. If it's a static IP, I wanted to use your modem as a guinea pig for the BGP iteration of the design. Yes, I'm placing design verification needs above your user satisfaction when I do that. :) I've been working with WE7X on a non-BGP static IP setup, but he's got an atypical situation going on there since he's a relay site. Not a good test case for the typical static IP scenario.

1.

2. How often are the DNS updates: Hopefully most people will (other than when setting up) will have low-frequency DNS updates, at least of nodes that they consider "critical".

Sounds like a reasonable description of the situation. No longer sure how it fit into the larger picture of the email. :)

1.

2. People's time: I'd guess that most of the people on this list have a full-time job. I'm probably the exception, being retired. Nevertheless, I have only so much time to give to *any* project as well. For that reason, I think simplicity is important.

Yup, as stated above, user experience being simple is important. You're experiencing an unfinished network with all the complexity out in the open. You've also made it harder on yourself by disallowing remote access for network operator folks. That's a personal choice you're of course free to make with your hardware, but I think it's safe to say we're not gonna stop pushing for our goals to keep the complexity you're chosen to take on low.

1. Continuity (eg, among project member changes) also suggests simplicity.

Also, good documentation. We're documenting things as they get finalized and publishing everything. Anyone not familiar with the project but familiar with computers/networking, should be able to surf that wiki and solve any problem.

1. Just one example:

I asked about a hostname automatically tied to my IP address. I don't *need* a fixed IP address. It would just be nice (not to mention simple) for some things (like running a DNS server!). And it doesn't even have to happen in the next two months (or more). But when I asked, the response was to offer to set me up with BGP, so that I can roam. A complex solution (?) proposed by someone who has very little time (and I don't want to take any more of that time than is necessary).

BGP isn't solely about roaming. It's also about security. The protocol stack I need to verify is to ensure noone else clones your MAC and steals your IP address and your traffic. The simple solution in this case (static DHCP) is really vulnerable and not suitable for wide deployment. See the Point to Multipoint Authentication <https://www.hamwan.org/t/tiki-index.php?page=Point+to+Multipoint+Authentication&structure=HamWAN> page for a (slightly outdated) authentication sequence and main communication mode between cell sites and clients. If this weren't part 97, things would be really simple. We'd throw WPA2 up on the APs and everyone would get a login. Sadly that encrypts things, so we can't use these industry standards on ham radio. We're forced to go to great lengths to remain both secure and compliant. You're experiencing the outcome of collective ham laziness not having yet invented the digital future.

For the radio I have, *I don't want to roam; it took too much effort to aim and mount the antenna !!!* (I presently have a pulled muscle in my lower back from climbing around on the roof.) If I want to roam, I will buy another radio and antenna (they're inexpensive enough), and when I roam, I either expect to have a varying DHCP address, *OR*, I will use my first radio to keep track of the second radio's whereabouts, just like I do now with my fixed IP-address DNS server in Boston keeping track of my ISP's DHCP-assigned IP address here at home, and updating DNS as needed.

I can confirm that when you roam, you'll indeed be able to pull DHCP. Another option you'll have when you roam is that after you've pulled DHCP, you can also engage BGP to announce a subset of your allocation. For example, if your home has a /29 allocated, you can announce just a /32 from that to your roaming client. The network will re-route that /32 away from your home and to your roaming client. Flexible!

Remember, I don't *n**eed* a fixed IP address or a hostname tied to it, all within the 44.x.x.x network. It'd just be nice. I have assigned "hamwan.ae7q.net" to my (first) radio, since it appears that the assigned DHCP address doesn't change across disconnects of more than a day. Yes, it won't be useful if only the 44.x.x.x network is available, but what have I lost?

Here are my interests in the HamWAN network, in decreasing order of "importance" (I have no plans to save the world in a catastrophe):

1. Network access to the Internet via HamWAN, that reasonably survives a low-grade catastrophe. I presumably have that now (but no guarantees). 2. Network access to the Snohomish County DEM site. That's more guaranteed than #1 above, considering generators at both sites. 3. Network access to the full 44.x.x.x network. I have no idea how meaningful this is. It's an area for tinkering.

Remember, I bought the HamWAN radio/antenna (that was my reason for coming to Puyallup this month), because of delays in the Universal Digital Radio project. I wanted something that works now, and Scott Honaker put me on to your project. I've now got something that works now, and am grateful for the effort (past, present, and future) that's gone into the HamWAN project by all that have been involved. I would just like to tinker (the amateur equivalent of "experiment") with some simple things without waiting for the grand solution.

What are we blocking in your tinkering? The two examples you mentioned (DNS and static IP) we can address right now. DNS we can do by hand, and static IP is fairly static for you even with just DHCP. I could do a temporary static DHCP assignment there but be aware of the hijacking issue I mentioned. The temporary period will expire when the Point to Multipoint Authentication protocol stack is verified and deployed. What kind of tinkering are you thinking of doing? Perhaps some of that information might drive some inputs to our design plans. I'd like to know how people use the network in general.

Now, what do others want? I have no idea. I would have thought that, in the past year, you would have more than a dozen or so participants.

Me too! I think hams are really into the theory of being on a microwave digital network, but not so motivated to go out and buy the hardware, configure it, install it, align it, and integrate it into their home network. I know of at least 2 examples where folks have actually bought the hardware and have been in a coverage zone for months, but just haven't deployed it. This may very well be a ham culture issue. Ham radio has been very focused on analog voice systems. Learning how to do digital network comms does take time and effort. Time changes all things though, and I'm encouraged by the new hams we've minted through this project. I'd like for us to focus on ham-recruitment of digital-savvy folks in the future. They may have an easier time of adopting HamWAN type technologies. And of course, we eventually need to get down to an appliance solution. There's a whole bunch of UI work involved with that. We need programmers!

How did your last two weekend presentations go?

As well as could be expected, I suppose. I'm pretty sure I lost both audiences, except for 1-2 guys in each one who had previous network experience. These deep-dive talks that focus on a specific subject are not appropriate for general audiences, so I'm calling my experiment a failure and will be using other methods going forward.

Granted that "location, location, location" is a big deal here, I can understand some hesitancy, but hey, the investment to try it out is minimal, especially with your "try it" offer.

Yeah, the trial offer needs more promotion. It's difficult to structure it though from an accounting and tax standpoint. That's why it's not on the front page. We need some financial people to bring this to a wider audience. Or just some other entity we can link to that can handle the trial hardware program. Perhaps some clubs can step up or something, I dunno.

Of course, we're all in a "fringe" area of interest in amateur radio ... too many think their handheld is what it's all about. I'm reminded of a huge multi-agency EmComm exercise a few years ago that I participated in. I was assigned as a radio liaison to a fire chief, and when he saw I had a nice camera, he told me to stow the radio and take pictures ...

BTW, I believe this is the longest email I've written in over a year. Gotta knock that off. :) --Bart

On Mon, Mar 31, 2014 at 11:02 AM, Bill Vodall <wa7nwp@gmail.com> wrote:

SSH had cipher=none. They disabled it. They removed it because somebody might accidentally use it.

The High Performance SSH folks put it back.

https://launchpad.net/~w-rouesnel/+archive/openssh-hpn

I'd start there if (when) I get back to 44 net use.

We started here, or at least are aware of it. The problem is that we don't know how to replace the SSH daemon that's built into ROS. Sure, we could run OpenWRT in a metarouter on the modem, then normal SSH from the metarouter to ROS (all within the CPU, encryption doesn't matter). A better solution would be to distribute a .npk that you can upload to your modem to replace the built-in SSH. Mikrotik does not provide an SDK for this, so we're trying to reverse engineer their package format to see if we can generate our own. In the meantime, I'll accept your argument that there's no obscuring of intent when using SSH for administration. And there's always telnet.

Who has the 44.44.44.44 address? 44.24.24.24 ?? That would make for interesting 44net or wwa.44net DNS access.

44.44.0.0/16 belongs to Massachusetts. 44.24.24.24 is unassigned. It looks like John Hays has been assigning /32s out of that range. We would need the whole /24 to be able to anycast it, so that idea is out.

The biggest problem - still - as I mentioned at dinner at Kirkland last year - is finding a use case and selling it. That's a bigger problem than all of these RF and TCP technologies. Alternate internet access is nice but not the magic silver bullet. Some of the other uses are nice but not the big thing everybody can use. I've heard 3 independent repeater discussions where folks were thinking and excited they could replace their existing $30 per month internet with $20 per month HamWAN. I don't believe that's a real option due to the Amateur Realm. (The answer is 'Facebook' but that's a different discussion which I hope to start on the 44net sig later this week...)

Did you ask them why they wanted internet at their repeater site? Surely not for YouTube! Maybe they want to link two repeaters together, ideally with low latency. HamWAN can do that, no internet required. It's cheaper and has better control that UHF links. I'm just curious what they actually want to do. Tom KD7LXL

On Mon, Mar 31, 2014 at 11:56 AM, Bill Vodall <wa7nwp@gmail.com> wrote:

These were general discussions on repeaters where folks wanted to replace their home Internet access -- out with Comcast and in with HamWAN....

Well, I'm glad they haven't shown up here yet. Those types of users don't really bring any value to HamWAN (nor would the majority of what they want to do be legal). Tom KD7LXL

.. I went to the Puyallup "Mike & Key" show for the explicit purpose of checking out HamWAN. It wasn't easy; after walking both floors, I returned to the show management table and asked for the HamWAN table location. After locating the table, I was surprised to a bunch of used stuff for sale (just like all the other tables), a few flyers, and a "funny looking" radio.

Those were extremely well done and very impressive flyers. Are they available on the web site? One of these years I need to figure out how to do the same for the NW-MESH and NWAPRS communities... Any suggestions on what tools to use? Bill, WA7NWP

On 2014-04-17 20:03, Bart Kus wrote:

...

...

When I exhibited at Puyallup several years ago, I was demonstrating my own (free) D-Star /radio/ (sic) and not selling anything.

You have a free d-star radio? What? :) URLs!

You snooze, you lose (grin)! Actually, "radio" should have been "software". I hate my keyboard, with all the mistakes it makes ... OT: Actually, I do have two Icom ID-880H radios for sale (like new, in box with all accessories, $300 each). Sales will fund additional MikroTik radio/antenna combos.

Yup, totally agree that's how you do a good booth. We do have portable demo gear as well. Little 21dBi dishes with modems dangling off em.

Which dishes? Any suitable dishes available where the MikroTik *attaches* and doesn't *dangle*?

...

Second, have *pictures* on the HamWAN web site of the radio/modem, and *especially* the antennas (with dimensions). ..

Wanna throw a better web site presentation together in this regard? I can hook you up with editor access.

Yes.

...

Third, and perhaps the most important, develop some "use cases" and document them to generate interest. ... *Post pictures of working sites (nodes and users)!* ...

These are all good ideas. Again, want to make them happen?

Again, yes.

What kind of speeds do you get on the Frontier? I heard they really rolled back since it was FiOS.

I just did a test accessing CenturyLink's test page: * Frontier FiOS: 25.6Mbps down, 12.0 up. * Comcast RG-6: 28.5Mbps down, 5.8 up. -- Dean

On 2014-04-18 14:10, Bill Vodall wrote:

...

I just did a test accessing CenturyLink's test page:

Frontier FiOS: 25.6Mbps down, 12.0 up. Comcast RG-6: 28.5Mbps down, 5.8 up. How does your HamWAN connection speed compare? I'm not seeing you (Dean's) node on the web site front page map.

73 Bill, WA7NWP

The MikroTik router is currently showing 6.0Mbps (raw) up/down @ -78dBm (see my next message on "dBm musings ...") I'll let whoever maintains the map add me. For reference, I'm at 47 51'40.38" N, 122 11' 23.34" W

On Fri, Apr 18, 2014 at 3:34 PM, Bill Vodall <wa7nwp@gmail.com> wrote:

...

without shared administrative access we can't read the link status for the map?

With the SNMP stuff I've been playing with for MRTG/Cacti - it's just a read only port. If so, maybe Dean would open that up for you.

It should be enough to complete the snmp section of the client node configuration instructions: /snmp set enabled=yes contact="#HamWAN on irc.freenode.org" /snmp community set name=hamwan addresses=44.24.255.0/25 read-access=yes write-access=no numbers=0 Tom KD7LXL

I have a grandfathered FIOS connection at 25/25 Just measured on Ookla 25.59 down 31.32 up 5 ms ping 1 ms jitter I bring Ethernet direct from the optical junction to 1 gbit Mikrotik router and it's a two hop 1 gb to the computer. ------------------------------ John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223 <http://k7ve.org/blog> <http://twitter.com/#!/john_hays> <http://www.facebook.com/john.d.hays>

Actually, what would be helpful (and motivate sharing of dynamic data), is for the text in those "click-on bubbles" for each site to indicate the "type" of data. Eg (these are just ideas; some of them are mutually exclusive): * Site survey 2013-06-07 * Static report 2014-02-14 * Dynamic report 2014-04-02 16:53Z * Online; status at 2014-04-20 17:37Z * Offline; last online 2014-04-19 02:15Z I hope you are enjoying your "new" radio; the other one is up on Craigslist. -- Dean On 2014-04-19 05:21, Cory (NQ1E) wrote:

Hi Dean,

I personally didn't real his comment on the map as snippy. However, I went ahead and changed it to something more generic.

Hopefully, we can restructure the mapping program at some point to rely only on data from the sector radios so we can avoid this issue in the future. One of the nice things about the NV2 protocol is that they share their signal strength information with each other. I've never tried it in access point mode for a client, but hopefully we can get it to work.

Also, nobody should be giving you any grief for deciding to maintain your own device. If you feel that someone is, let me know and I will take care of it. After all... We're all here to play network. Not just those who volunteer to maintain the cells.

-Cory NQ1E

On Fri, Apr 18, 2014 at 10:49 PM, Dean Gibson AE7Q <hamwan@ae7q.com <mailto:hamwan@ae7q.com>> wrote:

And I was going to, until I saw the comment when I clicked on my location on the map.

I will just ignore further snipping about my policy decision in this matter, unless it leads to me selling the radio.

-- Dean

On 2014-04-18 15:53, Tom Hayward wrote:

...

On Fri, Apr 18, 2014 at 3:34 PM, Bill Vodall<wa7nwp@gmail.com> <mailto:wa7nwp@gmail.com> wrote:

...

...

without shared administrative access we can't read the link status for the map?

With the SNMP stuff I've been playing with for MRTG/Cacti - it's just a read only port. If so, maybe Dean would open that up for you. It should be enough to complete the snmp section of the client node configuration instructions: /snmp set enabled=yes contact="#HamWAN onirc.freenode.org <http://irc.freenode.org>" /snmp community set name=hamwan addresses=44.24.255.0/25 <tel:44.24.255.0%2F25> read-access=yes write-access=no numbers=0

Tom KD7LXL

On 2014-04-20 21:45, Tom Hayward wrote:

On Sun, Apr 20, 2014 at 5:51 PM, Dean Gibson AE7Q <hamwan@ae7q.com> wrote:

...

Actually, what would be helpful (and motivate sharing of dynamic data), is for the text in those "click-on bubbles" for each site to indicate the "type" of data. Eg (these are just ideas; some of them are mutually exclusive):

Site survey 2013-06-07 Static report 2014-02-14 Dynamic report 2014-04-02 16:53Z Online; status at 2014-04-20 17:37Z Offline; last online 2014-04-19 02:15Z Dean,

I agree the map data could use more verbosity. These are the current types of map data: - Coverage (the red overlay) - Site (the radiation symbol) - Link (PtP between sites) - Client - Site survey (non-live client data)

All data are online/live unless labeled "site survey". Online nodes are represented by blue lines where the line width is related to the current negotiated link speed (this fluctuates a bit). When a client drops offline, the link line disappears and the signal strength shows "null dBm"--essentially no special handling in the software, the value just goes away. Signal surveys are gray lines, indicating a tested path but no connection.

The data is collected with SNMP into Cacti, then aggregated into a JSON file for the website. Javascript parses the JSON file and places the data on the map. I've been working on a portal website to allow people like you to edit DNS entries and edge firewall rules for your hosts. Eventually, I'll consolidate the map data into this database so you can update things like lat/lon yourself. Then I'll clean up the JSON a bit, and finally clean up the javascript that generates the map. If you'd like to jumpstart integration of your suggested changes into the map, you can start work on the javascript while I finish up the back end. Just click View Source on hamwan.org and you should have everything you need.

Tom KD7LXL

Questions (I've briefly looked at the JavaScript): 1. How often is the SNMP data from clients collected? 2. Is the data in a "client bubble" dynamic in the sense of refreshing every time a client location is clicked, or is a page refresh needed for a data update? 3. If the latter, I'm curious as to why we are using client-side (eg, JavaScript) rather than server-side (eg, php) processing. I use Google Maps on a couple of my web pages, and it works well with php. 4. Do you have to make a change to your database when SNMP data from a site comes online? I enabled SNMP data yesterday, but see no change in my listing. I would think that the best way to handle sites would be to treat everyone the same, and list SNMP data when available, on a dynamic basis. What would be nice in the data, is (as I hinted above) the date/time of the last signal strength, and of course its value. I'd think displaying the last signal value, even if months old, would be useful. From what I see of the JavaScript, that data is currently not available.

Dean, You may want to double check your firewall rules and SNMP settings, pings from the monitoring system are succeeding, but SNMP isn't coming through. Once that gets working, we can get the data added to the map. Thanks, Nigel K7NVH

On 2014-04-22 15:47, Dean Gibson AE7Q wrote:

I just enabled UDP port 161.

One little idiosyncrasy I've noticed in the MikroTik 5shpN: If you add lines to a list (say, the "/ip firewall filter" list), they are added at the end. Then, you can "print" where they are in the list, and "move" them to where you want them. You can't directly insert, but that's OK. Where the idiosyncrasy comes is, if you save what you did, and later paste it into the command line (without including the "print" command), it won't work. Apparently the numbering of the lines (needed for the "move" command) doesn't occur until you do a "print".

On 2014-04-22 16:16, Nigel Vander Houwen wrote:

Dean,

You can indeed place them where you like, using 'place-before=NUM' in your add command, and yes, numbering is dependent on you having performed a print.

Nigel

Thanks for the info, and the confirmation that the MikroTik command-line interface was nothing singling me out for torture ...

On 2014-04-22 13:15, Nigel Vander Houwen wrote:

Dean,

... 4. Yes. I need to configure the monitoring server to actually poll SNMP, and then we can tell the maps to use the RRD data. Since you say you've enabled that, I'll configure that now.

You are correct, since live data is based on the RRDs, if a client is disconnected, the latest RRD values will be 'U', and be presented to the javascript as nulls. I don't know that I'd replace that with the last good value, as that's no longer a true representation of the network, but I don't think I'd be opposed to having that data be potentially in the info box, though it would require some more work to set up.

Nigel K7NVH

You'd only show the last "old" value if you could show the date/time for it (and perhaps "thin" the connecting line). What would be really cool, is an app that captured (on a second-by second basis) and graphed (in the classical sense) the signal strength over time, either from your end or from the client's end. It would be especially helpful in setting up an antenna, rather than the bouncy values from "monitor" (I note that you can set the polling interval to a fraction of a second). Hmm, I wonder if Java (not JavaScript) has a decent API for SNMP (I presume that's the best way to capture the data).

Look at node.js for server side real time updates. ________________________________ John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223 On Tue, Apr 22, 2014 at 1:27 PM, Tom Hayward <esarfl@gmail.com> wrote:

On Tue, Apr 22, 2014 at 1:00 PM, Dean Gibson AE7Q <hamwan@ae7q.com> wrote:

...

Is the data in a "client bubble" dynamic in the sense of refreshing every time a client location is clicked, or is a page refresh needed for a data update?

No, it's all loaded when the page is first loaded. One of the enhancements for the map I'd like is background updates, so you don't have to refresh the whole page to update the map data.

...

If the latter, I'm curious as to why we are using client-side (eg, JavaScript) rather than server-side (eg, php) processing. I use Google Maps on a couple of my web pages, and it works well with php.

I'm not sure exactly what you're suggesting. Javascript places lat/lon points on Google's slippy map interface. This allows you to pan the map and zoom, and javascript will fetch the tiles for the new area, and move the Point to the appropriate new pixel coordinate for the lat/lon.

The only way to do something like this server side would be rendering an image, then rendering a new image every time they want to pan or zoom a new area. This would not be a good experience.

Tom

_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org

On Tue, Apr 22, 2014 at 3:54 PM, Dean Gibson AE7Q <hamwan@ae7q.com> wrote:

Here's what I do with Google Earth and php (because I'm moving domains, you will get a security exception for the time being, which can safely ignore): https://www.airmen.aero/logbook/FlightMap.php?LOGBOOK=A0672484&QUAL=

Scroll around and click, and see if it doesn't provide a similar capability. I see Google has changed the fonts; I think I need to increase the size of the bubble ...

That page has more than 3000 lines of javascript. Tom

On Fri, Apr 18, 2014 at 2:10 PM, Bill Vodall <wa7nwp@gmail.com> wrote:

How does your HamWAN connection speed compare? I'm not seeing you (Dean's) node on the web site front page map.

I added Deans location, but without shared administrative access (which Dean declined), we can't read the link status for the map. Tom KD7LXL

On 2014-04-18 19:06, Bart Kus wrote:

On 04/18/2014 01:59 PM, Dean Gibson AE7Q wrote:

...

...

Yup, totally agree that's how you do a good booth. We do have portable demo gear as well. Little 21dBi dishes with modems dangling off em.

Which dishes? Any suitable dishes available where the MikroTik *attaches* and doesn't *dangle*?

The little 21dBi guys still dangle. But, if you want direct-attach, here are a couple options:

http://www.antennas.com/dish-antennas-2/dual-pol-dish-antennas/

Thanks! However, for portable use, I think I'm looking for something with a little larger beamwidth, maybe 20-30 degrees. Bill's list looks reasonable.

Beware the shipping on the larger (3ft) one, it can be a killer. The smaller (2ft) one is reasonable though. You'll need a right-angle N connector (supplied with 5SHPn) to fire up the H-pol. The 2ft dish will have lower gain than the Poynting though, so beware. The 3ft dish will have higher gain than Poynting.

...

...

...

Second, have *pictures* on the HamWAN web site of the radio/modem, and *especially* the antennas (with dimensions). ..

Wanna throw a better web site presentation together in this regard? I can hook you up with editor access.

Yes.

OK, what's your username on the website? Have you worked a tikiwiki before? Perhaps install a copy locally to practice the syntax/format/plugins/etc. Feel free to drop into #HamWAN for real-time editing help.

I've used a wiki a small amount before. Probably the best thing is to create an near-empty page for me to start in. I didn't know I had a username on the web site. If you are referring to my name in the mailing list, it's "Dean Gibson AE7Q".

...

...

What kind of speeds do you get on the Frontier? I heard they really rolled back since it was FiOS.

I just did a test accessing CenturyLink's test page:

* Frontier FiOS: 25.6Mbps down, 12.0 up. * Comcast RG-6: 28.5Mbps down, 5.8 up.

Are those in-line with the advertised "service speeds"?

I think so.

BTW, if you're doing Bill's request for Internet speed, feel free to also do a /tool bandwidth-test to your next-hop for HamWAN. That'll show where the slow-downs are. Either on the link to you, or somewhere deeper in the network/Internet. You may have to open the firewall some more to allow the right packets through for that test. The bandwidth-test server on sector 2 is wide open, no authentication required.

ps: Please delete my "pending" eMail sent to the list with the wrong "From" address.

On 2014-03-31 13:51, Tom Hayward wrote:

On Mon, Mar 31, 2014 at 11:02 AM, Bill Vodall <wa7nwp@gmail.com> wrote:

...

SSH had cipher=none. They disabled it. They removed it because somebody might accidentally use it.

The High Performance SSH folks put it back.

https://launchpad.net/~w-rouesnel/+archive/openssh-hpn

I'd start there if (when) I get back to 44 net use.

We started here, or at least are aware of it.

Excellent! I will make heavy use of this. I have a site to site VPN with the FNF colocation center, and hate the double overhead. Very cool stuff.

The problem is that we don't know how to replace the SSH daemon that's built into ROS. Sure, we could run OpenWRT in a metarouter on the modem, then normal SSH from the metarouter to ROS (all within the CPU, encryption doesn't matter). A better solution would be to distribute a .npk that you can upload to your modem to replace the built-in SSH. Mikrotik does not provide an SDK for this, so we're trying to reverse engineer their package format to see if we can generate our own.

Hmmmm. Interesting. Is https://github.com/lqez/npk the same npk that mikrotik uses? Also I stumbled across: http://ayufan.eu/projects/openwrt-rb951g/ There are few possible ways to get the OpenWrt to the device. The most simple way is to use fixed MikroTik’s Netinstall. I modified the binary to allow install unsigned and custom built NPK files (MikroTik’s RouterOS Package Files). Read this page: http://wiki.mikrotik.com/wiki/Manual:Netinstall Instead of Netinstall provided by MikroTik use the fixed one: netinstall-5.23-fixed Select and install OpenWrt package: openwrt-r35489-13.0alpha1-mipsbe Switch the cable from port 1 into any other. Wait for reboot and telnet 192.168.1.1. There are different methods, but they require to setup own DHCP and TFTP server and configure BOOTP protocol. All the files required to install using bootp can be found here: rb951g-raw-bin So maybe you can package up a whole distro image (including your customized sshd) and reflash?

In the meantime, I'll accept your argument that there's no obscuring of intent when using SSH for administration. And there's always telnet.

Yes with sufficient ACLs and other security mechanisms, you can operate a completely safe and secure network without any encryption.

On Mon, Mar 31, 2014 at 11:02 AM, Bill Vodall <wa7nwp@gmail.com> wrote:

The biggest problem - still - as I mentioned at dinner at Kirkland last year - is finding a use case and selling it. [...]

(The answer is 'Facebook' but that's a different

discussion which I hope to start on the 44net sig later this week...)

Obviously you haven't heard that the Internet is controlled and architected by 15 year old girls. Facebook wouldn't be a very good killer app for this. I really doubt anyone cares that K7LID (fictitious) worked a pile-up on 20 with his 4 stacked quads running *cough*legal*cough* power and the 200 likes that back it up from that. I'd stack up my radio gear and set fire to it at Puyallup if the world came to that. Streaming Video/Audio and shared data is the killer app.

I'd suspect this would be a common interest in HamWAN.  Right now, anyone setting up a web site on the 44.24.240.x network is subject to IP address changes without a hostname being used to hide the issue.

Static IP addresses are good. Especially since you all have a /20 of em. But in the interim, just use a dynamic DNS client and one of the free services. Simply CNAME the domain name to the dynamic hostname and you'll be all set. I did that back when I ran services out of my house off DSL. Now I colo everything and never have to worry about it.