- PSDR - mailman.hamwan.org

How does client authentication work?
by Bart Kus 18 Mar '13

18 Mar '13

Now taking proposals. It's turning out to be a non-trivial thing to implement in a way that's not hijackable, and only allows registered hams onto the network, while not using encryption in prohibited ways. Thoughts? --Bart

3 4

MicroHAMS Digital Conference - March 23, 2013
by Kenny Richards 16 Mar '13

16 Mar '13

I just wanted to put out one final reminder for the MicroHAMS Digital Conference, which is next Saturday.(3/23/13) I will be taking down the registration page on Monday morning, at that point you'll need to register at the door. 73, Kenny, KU7M Event information is available here: http://www.microhams.com/mhdc (Here is the original announcement) I'm happy to announce the six annual MicroHAMS Digital Conference! The event is scheduled for March 23, 2013 and will again be held on the Microsoft campus, located in Redmond, WA. The agenda this year is a little different then previous years, rather then covering a wide variety of topics, it is focus on digital networking. We have talks about two local efforts which are currently underway and are leveraging off the shelf wireless networking technology for Amateur radio. The NW-MESH effort is a spin-off of the ARRL HSMM program, which has been getting lots of traction the last couple months. The HamWAN project is attempting to provide a high speed wireless backbone for the greater Seattle area and we'll get an update on its status. Additionally the guys from NWDigitalRadio will be back to give us an update on the very cool UDK56K digital transceiver, which was one of the coolest things announced at Dayton last year. (And we got a sneak peak at MHDC last year) Finally we'll get a run down of interesting things you can do with the Raspberry Pi, which is being leveraged all over ham radio since its introduction last year. Because of space limitations and parking requirements on the Microsoft campus, we are strongly suggesting pre-registering for the event. Registration is $30.00 if done prior to the event and will be $35.00 at the door. We have a web-based sign-up form (details below) and have arranged pre-payment via the Paypal service. (No Paypal account is necessary) In addition to the presentations, a demo area will be setup along side the conference space and door prizes will be given away. Event Details Date: March 23, 2013 Location: Redmond, WA (on the Microsoft campus) Time: 8:30 to 17:00+ Lunch: Sub sandwiches (provided) After Event: Pizza Gathering (local pizza place, to be named later) Cost: $30 if pre-registered and $35 at the door Registration Available Now! (See the site) Agenda Available on the site (http://www.microhams.com/mhdc)

1 0

Re: [HamWAN PSDR] Mesh backbone
by Bart Kus 16 Mar '13

16 Mar '13

KY9K de AE7SJ Awaiting your response, but I'll address Gerard's comments here since he's waited quite a while. On 3/14/2013 12:01 AM, Gerard Hickey wrote: > > First of all, (Bart I am not trying to start a fight, just making an > observation) No one is trying to start a fight, but we do have inherently contentious issues to discuss. So let's keep a cool head and keep the communication going for the good of the community. > HamWAN is not a mesh network. It is an architected network with links > (both real and planned) spread out throughout the region. This is where we hit the inevitable confusion over the phrase "mesh network" which I addressed at the top of my first response so there wouldn't be any such confusion. Let me find it ... -=[ QUOTE ]=- First, let's speak the same language. There's a lot of confusion around the word "MESH". I'm also not sure why it's always capitalized. It's not an acronym as far as I know. The term "mesh network" describes nothing more than the logical topology of a network. There's a really good write-up on this at the wikipedia page <http://en.wikipedia.org/wiki/Mesh_networking>. I'm pretty sure that when you (and others on this email) use the phrase "mesh network" it is not the wikipedia definition you're intending. It means something different, including: 1) Using a common RF channel 2) Promiscuous neighbor discovery + association 3) Automatic IP configuration based on MAC 4) Nearly open node authentication 5) Omnidirectional operation 6) WDS <http://en.wikipedia.org/wiki/Wireless_distribution_system>-style operation These are the typical traits of a SeattleWireless <http://seattlewireless.net/>style mesh network (which, BTW, has been attempting to bootstrap itself for the last 13 years). This type of definition of "mesh network" is quite a different animal from the canonical mesh network definition (wikipedia's, derived from network theory). The reason I want to make the distinction clear is that nearly all large networks in the world are indeed mesh networks, but nearly none of them possess the qualities of 1-6. So when I say something like "HamWAN <https://www.hamwan.org/t/tiki-index.php>is a mesh network", I want it to be clear that I'm referring to the network topology only (the wikipedia definition). I'm not sure what is the right word to describe the other type of network; perhaps capitalizing all the letters is a good differentiator after all. :) -=[ /QUOTE ]=- > Two of the qualities of a mesh network is self-healing and zero > configuration. So, admittedly I did pull the list of the above 6 properties out of my butt. It's my best guess. Is there actually a formal list somewhere? Please provide it. I don't think there's actually any clear divide between MESH or not, it's more like a spectrum of features that are there or not. I would argue the "zero configuration" claim is not actually true. There's configuration in MESH nodes, it's just stored in the node router, much as it will be in HamWAN client routers. You set things like frequency, bandwidth, SSID. In fact, as I understand it, there's usually a custom firmware that's uploaded which comes with I don't know how many settings that I'm guessing are set "just right" so that things work nicely. So here, we're not so different, as both client router devices will have a config set. The other way I can interpret this is that once you get your fully configured client router device, you simply attach it to an antenna and it finds and connects to the wireless network. This is exactly the scenario we're enabling for HamWAN as well, it's not unique to NW-MESH. OK, maybe one slight difference: in the HamWAN case there will be user credentials you enter into the router for it to authenticate onto the network. But isn't there some OLSR key in NW-MESH? I'm really not up to speed on that as much as I should be. > Yes, HamWAN does have self-healing properties but it is an engineered > healing mechanism rather than a intrinsic part of the technology. I'm failing to understand the difference between "engineered" and "intrinsic" here. If we require that HamWAN run OSPF, this becomes an intrinsic property of HamWAN. OLSR is REALLY close to OSPF. I would say in the self-healing aspects, the networks are not very different at all. > I also can not just by the same hardware that HamWAN is using, turn it > on and point it to a HamWAN point of presence and have it work. There > are specific network and routing parameters that need to be set in > order to come up on the network. I addressed this "zero config" claim above, but do correct me if I'm wrong. > Just the same as if I have a configured HamWAN installation, I could > not move it to another part of the region, point it to another point > of presence and be back on the network (actually there is one or two > ways, but it makes the routing butt ugly). This is actually one of the scenarios we're definitely enabling. If you have a static IP or subnet, it will follow you around on the network no matter what sector you connect to. In one of my previous replies I also described how that static (and publicly routable!) address(es) can follow you to partner networks as well through use of VPN peering. Nice, ya? :) This is why we're using beefy routers, cuz we expect the routing tables to be large. > > With these statements, I am just trying to provide a clearer > distinction that Bart started in the second or third email of this > thread. By no means am I trying to elevate one technology or the other > as a superior technology. I think that there is plenty of room for > every one to experiment and play with the various technologies. I whole-heartedly encourage any activity which gets hams playing with more modern digital stuff. The whole concept of "superior" or "best" is relative to your goals. That's why I'm trying to get some sense out of the NW-MESH crowd of what the goals really are. A mission statement or something. Like I've said, I think our goals are actually pretty close in most areas, and it's the differences I'd like to explore to see if we can minimize them or respect them and work on a peering model. If we develop a clear understanding of each others' goals, only then we can begin the technical work necessary to align the networks together. > > I have stated since I first heard Bart speak about the HamWAN project > last year at Summer Gathering that it works very well as a backbone > technology. I think it compliments the NW-MESH work very well in the > sense that it can tie together various NW-MESH networks and provide > the backbone between them. And NW-MESH provides an economical way for > hams to participate in a community network. The economics of onboarding to HamWAN (~$200) vs. NW-MESH (~$30) is a fair point. I can envision a neighborhood cluster of $30 nodes sharing a $200 uplink. But for this to become reality, we must agree on how to align. I'm starting to sound like a broken record. :) The initial thinking of "just give us a tunnel" is a raw deal for HamWAN, so we must work harder to strike a better balance. I'd like HamWAN clients and MESH clients to be mutually directly addressable, for one. I have other concerns about route injection into HamWAN, client authentication on NW-MESH and potential collisions with people's RFC1918 space networks since HamWAN does intend to announce routes into people's home networks. I'd also like to understand the QoS, default gateway, DNS, IPsec and IPv6 stories. There's a LOT of work to sort out. Let's not waste time in jumping to it. > >> Do you have a favorite low-noise public meeting location with power >> + wifi? Starbucks is sounding likely. > > I have never seen a Starbucks be low-noise. Anyone of them I have ever > been is has always been fairly loud with all the sound reverberating > of every flat surface (I swear that every Starbucks employee is taught > to bang pots on every surface behind the counter). I am sure that I > can be proven wrong as I am not a coffee drinker and do not visit > Starbucks that often. > > What I will offer is conference rooms at ebay in Redmond. We have > plenty of white boards and projectors / 60 monitors for presenting so > that everyone does not have to crowd around one laptop. We can meet > pretty much most nights or weekends except for Tuesdays and the 2nd > and 4th Monday of the month. This Friday and Saturday is also out > since I will be at the Cascadia IT conference. I will also be in > California the week of 3/25. Beyond that I think I can pretty much > make anything else work. I'm game. Since I work in Redmond, I can be available there any weekday (after work), and am willing to make weekend trips whenever others can do likewise. Let's get the ball rolling here. During the first meeting(s) whoever is attending should be prepared to discuss their goals and philosophy about these networks. --Bart > > 73. > -- > Gerard Hickey / WTØF IRLP:3067/Echolink:529661 > hickey(a)kinetic-compute.com <mailto:hickey@kinetic-compute.com> > 425-395-4554 > >

2 1

HamWAN Response to FCC NPRM 13-22
by Bart Kus 14 Mar '13

14 Mar '13

For those unfamiliar with the issue, we are dealing with the FCC removing protections of Amateur Radio spectrum in the 5GHz band. I have attached the exact (lengthy) FCC publication which announces this intention. Page 6 shows the graphical view of what they're proposing. Paragraph 97 on page 31 covers details of U-NII-4 rules, which sums up to it's OK to run high power, and it's OK to run it outdoors. This is big trouble for amateur radio in this band, as amateurs will be denied entry onto sites that use this spectrum for unlicensed but commercial reasons. We cannot compete with the money changing hands between commercial WISPs and site owners. Below is what I've drafted as a response to this proposed ruling. Please read it over and comment. We only have a few weeks to file the response and generate popular support to sway the FCC's opinion. Please spread the word through the amateur radio community. I have posted this message on our website at: https://www.hamwan.org/t/tiki-index.php?page=HamWAN+Response+to+FCC+NPRM+13… for easy sharing with others. *HamWAN Response to FCC NPRM 13-22* The new U-NII-4 band allocation and U-NII-3 25MHz expansion for unlicensed users will cause many problems for Amateur Radio networks operating in that spectrum.I would like to point the commission to an example of one such band plan for the HamWAN network: https://www.hamwan.org/t/tiki-index.php?page=Spectrum+Allocation&structure=… To summarize the spectrum here textually, it is: Guard Band: 5.835-5.845GHz Channel 3 @ 240 degrees azimuth: 5.845-5.865GHz Guard Band: 5.865-5.875GHz Channel 2 @ 120 degrees azimuth: 5.875-5.895GHz Guard Band: 5.895-5.905GHz Channel 1 @ 0 degrees azimuth: 5.905-5.925GHz This arrangement allows co-existence of Amateur Radio digital networks on high up and densely populated radio sites, alongside commercial wireless service providers. It has been HamWAN's experience that site owners, when deliberating Amateur Radio admission onto such sites, are primarily concerned about the impact to these unlicensed commercial wireless service providers.So even though Amateur Radio licensing in the 5.65-5.925GHz range technically allows priority access to these frequencies for amateurs, the reality of the situation is the exact opposite.Financial benefit to tower site owners is the true arbiter of spectrum usage at prominent sites.Amateurs have no chance of competing with commercial spectrum interests in this band.The U-NII-4 allocation, and the 25MHz U-NII-3 expansion effectively deny access to the frequencies for amateur usage at sites required for network creation. Given that there is great momentum behind deploying these free-to-use amateur networks right now, this will force the amateur community into a contentious position with the unlicensed commercial users of the spectrum, particularly at popular tower sites.Amateurs will be forced to use the only tool left available to them, and that is to file complaints of interference against the unlicensed users until their operations at popular sites are either shut down or moved to different spectrum. HamWAN would like to achieve a peaceful co-existence with existing wireless network providers, by leveraging the amateur portion of the 5GHz spectrum as much as possible, before opportunistically sharing the rest of the U-NII spectrum.This view of cooperation is shared by other amateur organizations. In summary, please consider the value that non-commercial microwave networks delivered by amateurs provide to their communities, and please revert the U-NII-4 allocation along with the 25MHz U-NII-3 expansion.We do not oppose the other changes in NPRM 13-22. Signed, Bart Kus HamWAN Chairman

1 1

Re: [HamWAN PSDR] Mesh backbone
by Bart Kus 13 Mar '13

13 Mar '13

Hi Craig, First, let's speak the same language. There's a lot of confusion around the word "MESH". I'm also not sure why it's always capitalized. It's not an acronym as far as I know. The term "mesh network" describes nothing more than the logical topology of a network. There's a really good write-up on this at the wikipedia page <http://en.wikipedia.org/wiki/Mesh_networking>. I'm pretty sure that when you (and others on this email) use the phrase "mesh network" it is not the wikipedia definition you're intending. It means something different, including: 1) Using a common RF channel 2) Promiscuous neighbor discovery + association 3) Automatic IP configuration based on MAC 4) Nearly open node authentication 5) Omnidirectional operation 6) WDS <http://en.wikipedia.org/wiki/Wireless_distribution_system>-style operation These are the typical traits of a SeattleWireless <http://seattlewireless.net/> style mesh network (which, BTW, has been attempting to bootstrap itself for the last 13 years). This type of definition of "mesh network" is quite a different animal from the canonical mesh network definition (wikipedia's, derived from network theory). The reason I want to make the distinction clear is that nearly all large networks in the world are indeed mesh networks, but nearly none of them possess the qualities of 1-6. So when I say something like "HamWAN <https://www.hamwan.org/t/tiki-index.php> is a mesh network", I want it to be clear that I'm referring to the network topology only (the wikipedia definition). I'm not sure what is the right word to describe the other type of network; perhaps capitalizing all the letters is a good differentiator after all. :) So, with the definitions out of the way, let me address your actual email now that I can speak to it unambiguously. I concur that we all want to implement a mesh network, but I don't think everyone wants to implement a MESH network. Phrasing the problem of "how do we provide modern digital communications to the ham community" in terms of "how do we implement a MESH network" is putting the cart before the horse. Over the last 6 months, I've been leading the HamWAN effort to create solutions to the first question. We've made respectable progress on both the RF engineering and networking fronts. We had a fully functional cell site setup @ last weekend's Flea Market. This site design is about to start rolling out to the real world. This transition in the project's status has allowed me to start thinking about how HamWAN might integrate with other ham networking efforts. We've had a good relationship with BCWARN.net <http://www.bcwarn.net/intermapper/rf-map.html> for the last few months, and integration with that network will be simple. The physical links are already planned in fact! We're both excited to make it happen and start exchanging traffic internationally! The integration with NW-MESH efforts is far more challenging. In fact, it may be outright impossible unless changes are made in the NW-MESH design. From what I've seen, this difficulty of peering will be present in all MESH networks. The problems range from simple route exchange, to address space conflicts, to policy propagation (access, QoS, filtering, etc). I don't even wanna think about DNS. :P Having said all that, there is some value to HamWAN using a MeSh (hybrid of mesh and MESH) layer. Traffic between nodes may flow more optimally on the ground than through the mountain sites. A nearby ham who doesn't want to invest in a dish might get on HamWAN by MeShing with his neighbor. I'd be good for the health of HamWAN to make use of these optimizations. But like I said, in order for these routing decision to be made correctly and automatically, NW-MESH designs will need to change. I'd like to invite you (in fact, all of you) to join the HamWAN weekly meeting today @ 7PM. I'll re-send the connectivity details on the mailing list (email: psdr-join(a)hamwan.org) an hour before the meeting, but basically install Mumble <http://mumble.sourceforge.net/> 1.2.4 <http://mumble.info/snapshot/mumble-1.2.4-rc1-8-gb115a29.msi>+ (currently beta), and connect to BartK.us. Please use a headset to avoid generating echoes. Craig, can you give me an idea of your skills? Perhaps you would enjoy solving these types of problems as part of the HamWAN development team? We run a tight ship with specific assignments and weekly reporting. I believe this is the "small group of experts" approach you were proposing. :) --Bart On 03/12/2013 12:09 PM, Craig B wrote: > When I first heard about the MESH project from Daniel Stevens (KL7WM) > back in late fall 2012, the first question I had for him was "what > will it connect to?" Since then, as I have become more involved I > have started to formulate what I think it could be connected to and > how it could be used. > > Based on what I have learned and seen to date, I see 3 tiers of > network involved here. The backbone, which I see as a long-haul that > would be based on a region that is defined by terrain and distance. > The middle tier would be smaller and could be between HAM towers or > other "secondary" sites. The 3rd tier would be for the "neighborhood" > or "home" MESHing with WRT's and other low-power devices. In this > type of configuration, I see the backbone as being the one common > piece across regions while the secondary and tertiary tiers could be > specific to the 'regional' implementation. Each tier would have to > bridge from itself to the next level, which seems to be reasonable > where a given site could choose to bridge by adding necessary hardware > or remain remote. > > What I would like to do is see if we can't get a written network plan > for a regional backbone and then any additional tiers that need to be > included in a good network design document. I am a firm believer that > it should be hardware agnostic for the most part, although could > provide a list of acceptable components that have been shown or > believe to be the best hardware based on application. It would also > dictate how traffic might be handled moving up/down through the tiers, > possibly allowing for QoS or other transport methods. > > As I am sure we all want to see a MESH network available to all HAMs; > given the area NW-MESH has been getting feedback on, I think we need > to start looking at how we connect them all together. As such, in > talking with Bob Rutherford, it seems like the first step is to build > out a plan that could be presented to FWARC, Tukwila Radio Club, and > EMCOMM (and other clubs/groups). > > Since this is all great in theory, it seems the next step is to secure > funding and move it from paper to reality. Given the real application > of this MESH network for EMCOMM, and their generally deep pockets, it > seems like a great way to get a backbone built. > > If we are going to design this, I believe it needs to be initially > designed by a small group of network and radio experts. Once an > initial plan is cobbled together it could be released to the larger > MESH community for comments and additions/subtractions, etc. > > I am willing to take on leading this charge; however, I will need a > team of experts behind me helping lay the ground work. My initial > thought is to have something ready by mid or late summer, given that > we all have other priorities as well, not adverse to taking longer if > it means having a complete and well planned out design. > > Any thoughts on this? > > Thanks, > Craig > KF7LLA

3 5

Meeting notes March 5th, 2013
by Bart Kus 12 Mar '13

12 Mar '13

1) Ben published draft bylaws. We'll review/tweak this week, and then submit for voting. He's continuing to investigate insurance policy. I need to forward MicroHams policy info to him. Ben will help with setup on Friday by way of truck. Ben's also putting together the server/switch side of the Flea Market demo. Setting up asterisk as one service. 2) Curt got us a 50 minute presentation @ SeaPac!!! Details forthcoming. He'll forward background image to Ben for banner creation, and will submit own design if possible. Curt will engage with Seattle ACS folks to see how HamWAN can help their emergency activities. BANNER DESIGN MUST BE SUBMITTED TOMORROW 3) Cory's back and working on 802.1x/authentication. Was off the last 2 weeks. Will supply SIP phone for Flea Market. 4) Rob couldn't attend but here's his update: Greetings all, I will be unable to make >this< meeting tomorrow, due to >another< meeting. Perhaps we should have a meeting about scheduling meetings? (no, just kidding) 1)Rotor control software progress -- moderate, but not nearly fast enough. Availability of time is the issue. 1^st run in VB is probably 75% along. Got the cable back from Scott so I can test. Need to pick someone's brain on the interface to the test equipment. Do I simply poll for whatever value is presented (i.e. the TE is continuously sending output), or do I need to send a command parameter then get a response, etc, etc. 6)It looks like I will be going to Puyallup after all. Previous commitment has been cancelled. Not sure how much time I'll have between now and then, but what needs to be done? (I'm really going to hate myself for asking that...) I cannot be there late as we do have other commitments that evening around 6 up north. Rob 5) KD7ILD will contact Housing Authority about hosting sites. Focus on Beacon Tower. Other site development in progress as well. 6) I'll setup the cell site here and generate OpenVPN creds for people to dial in and make sure everything is working prior to the Flea Market. General discussion points: 1) We'll go with the full blown RF analysis display @ Flea Market. Heavy, but nifty. There will be enough people to cover the table so things don't get messed with. 2) New member "megor" has promised to get his ham license this Saturday. Go Team Megors! 3) Banner printing will have to be local / quick. FedEx is looking likely. I'll check their rates. 4) We postponed the discussion on the FCC's Notice of Proposed Rulemaking. I need to draft a response and have the board sign it on behalf of HamWAN. Send it to state rep and ARRL and FCC? We'll figure that out. Many other finer points were omitted from this email.... --Bart

1 2

Presentations
by Bill Vodall 08 Mar '13

08 Mar '13

> 2) Curt got us a 50 minute presentation @ SeaPac!!! Details forthcoming. > He'll forward background image to Ben for banner creation, and will submit > own design if possible. > BANNER DESIGN MUST BE SUBMITTED TOMORROW You're getting well prepared for these presentations.... Here's a techy local event asking for presentations that's sadly lacking any HAM radio presence... http://linuxfestnorthwest.org/ I've attended the last few of the Linux fests. It's not great but it's not bad and a good excuse to get out to do something different. There has been talk of a Xastir demo but nobody has had the time. 73 Bill - WA7NWP

5 9

FCC Notice of Proposed Rule Making (NPRM) 13-22
by Bart Kus 05 Mar '13

05 Mar '13

Attaching an FCC notice which affects HamWAN and all ham users of the 5GHz band. Have a read. So long. --Bart

1 0

Agenda for tomorrow's meeting (March 5th, 2013)
by Bart Kus 05 Mar '13

05 Mar '13

Hello, 1) Rob will update us on rotor control software progress. 2) Ben will update us about insurance policy details, and will present bylaws document. 3) Curt will update us on the Banner front for the Flea Market, and on future bookings, especially SeaPac. 4) Cory will update us on 802.1x/authentication research work. 5) We will discuss and settle on the Flea Market plan of action. Times when we'll meet to take specific hardware to deploy on Friday evening. Who will attend @ the opening on Saturday and throughout the day. Who will be doing teardown and when. 6) Flea Market demo commitments. What scenarios are being realized and by who exactly? I've personally got to build the cell site (physically+network configs) and have to share it via OpenVPN with others building other parts of it. The central switch/router is not here yet to do this, so it might be challenging. 7) We need to respond to the FCC's intent to rule on further allocations in the 5GHz band. Their plan is to completely overlap the amateur radio allocation there with U-NII services. This puts us in a very bad spot spectrum-wise. 8) Site development work. DNR and others. Inviting KB7ILD and Mike Ping explicitly for this. If you'd like to append to this agenda, please respond to this email with your needs. New attendees welcome! You may walk away with work though. ;) *Meeting Details* *How* Mumble <http://mumble.sourceforge.net/> voice + text chat software (v1.2.4+, install the beta if needed) *Where* Connect to server "BartK.us" *When* Tuesdays @ 7:00PM PST for 1 hour *How* Please use a headset or enable Echo Cancellation --Bart

2 1

Shields up, captain!
by Bart Kus 01 Mar '13

01 Mar '13

And despite all that, the attenuation between TX+RX antennas is still 65.5dB! This must be reflections internal to my garage. Gotta re-run these measurements outside. Also, the angles on the shield are too shallow. I gave it a 130 deg opening, but the back is recessed from the active elements of the antenna, so this doesn't actually shield as much as it should. It'll be fun to see this on the radiation pattern measurement range! See before + after. Might have to use a wider shield. This is 2ft by 1ft sheet. The bolt pattern won't work for production use. In real life, if these shields are to be used, they'll just hang on via the 2 mounting bolts at the very center of the back of the antenna. You can just see their nuts pointing up in the last picture. Undoing all the other bolts while the antenna is inside the radome would permanently break the antenna. Spacers would get knocked loose, and you'd have to destroy the radome to re-align things. This antenna is entirely metric. Horizontal spacing between all bolts = 6cm. Spacing between the upper/lower bolts and the inner bolts = 20cm. Spacing between the inner bolts = 6.8cm. Holes are fine with 1/4" drill. Bolts are M10. --Bart

2 1