Regardless the merits and issues of the APRS infrastructure and authentication schemes; KUDOS!! to KB3VWG for providing a 'SERVICE' on the 44 net with managed access for the rest of the Internet. This is exactly what we need much more of.. Bill, WA7NWP PS. Double KUDOS if the actual server is being accessed on Ham RF and not just a network tunnel.

I also have an LoTW certificate; but you can't verify a cert unless it's CA is online. Last I checked, LoTW's CA wasn't. -KB3VWG

Marc, Thanks. In fact, I used the callpass program in the Xastir application, free and open source. I simply installed it on a 32bit and 64bit PC and copied the callpass program. -KB3VWG

TL;DR: LotW is perfect for many of our use cases and I explain why/how it works. If done right, it's even possible to use it on our RF links without violating the rules. I also clear up some other misunderstandings from this thread. The entire point of the certificate system as we know it is to establish the trust of someone's identity through a third party that you already trust, all without being online. If you already have a copy of and trust the well known ARRL root CA certificate, then that's all you need to automatically trust any other certificate that is signed by it. Because there's a chance that certificate can become invalid at some point in the future (call sign change, private key exposure, etc), ARRL mitigates the risk by limiting its validity with an expiration date of at most two years. Some other certificate authorities will also offer a service that allows clients to check the status of a certificate's revocation status in real-time, but it's optional and not supported by ARRL's CA. The LotW certificate system was created so that contesters can have a way to sign their logbooks in a way that anyone who trusts the ARRL can verify, which prevents cheating. The ARRL has a system setup that allows any global ham to get their license verified and get a certificate for no cost. Because of this, it makes perfect sense that other internet based systems can be setup to trust ARRL to vouch for the identity of other hams when granting access to those systems. This type of setup is not difficult to do on the internet and there are plenty of use-cases where it makes sense to do so today. However, when providing services over our RF links, we need to be careful not to "obscure the meaning of messages" as written in our rules. This rule is a good thing, as without it our valuable spectrum may have been taken over long ago by commercial interests who secretly use it for other purposes. Many people mistake this for a ban on "encryption" which is actually just a math based tool that *can* be used to obscure messages. Using encryption algorithms to sign otherwise unobscured messages does not fall under this category. A good analogy would be recognizing someone you know on the air by the sound of their voice. Their words are the content, but their voice is the signature used to trust who is sending you that content (and not a form obfuscation). SSL is only one method of achieving this and it is possible (although difficult) to make it RF compatible. SSL typically gives us three things: Privacy (so our messages can't be heard by others), Authentication (so we know who we're talking to is legitimate) and Integrity (so we know the message hasn't been tampered with while in transit). Most people only think of privacy when thinking about SSL. However, it's easy to turn that part off on the server side so we only have the two other benefits, while leaving all the messages themselves in the clear. The difficult part is that all known web browsers have disabled this capability by default in order to protect their users from servers who may have "accidentally" enabled SSL without privacy (also known as "null cipher encryption"). It's hard for many on the internet who aren't hams to understand why this would be a valid use-case, so we need to show them whenever possible. You may want to help by "starring" this feature request<https://code.google.com/p/chromium/issues/detail?id=58831#c22>… Google Chrome so they eventually pick it back up. Of the browsers that claim to allow re-enabling this functionality, we've only been able to get it to work on the older Opera 12.x branch. Tom has started a good document<https://www.hamwan.org/t/tiki-index.php?page=SSL+without+Encryp… how to set it up so you can connect to HamWAN's self-service admin portal without encryption while logging in with your LotW certificate (passwords are bad on a link that is not private). Sorry for the length, but hopefully this clears up some of the confusion on this topic. Let me know if you have any questions. -Cory NQ1E Radio Hacker On Thu, Apr 17, 2014 at 1:51 PM, &lt;lleachii(a)aol.com&gt; wrote:

I don't think you can read the HTTP GET in SSL. If this was the case there would be no problem in building vhosts with SSL. The only think you can read are the lower layers, aka, mac src dst, ip src dst, tcp packet headers but the content itself (the http package) will be encrypted and thus unreadable in plain english. 73s Robbie ON4SAX On Fri, Apr 18, 2014 at 1:37 AM, &lt;lleachii(a)aol.com&gt; wrote:

I'll be honest Robbie, I haven't sniffed an SSL packet in a long time; but since we can both agree that the FCC regulates radio (Layer 1/Link Layer - 802.11) and not Layers 2 and above, going backwards through the OSI/DARPA Model, we find the radio transmission at Layer 1, which is not obscured, nor is: Layer 2,3,4,5, 6 or 7 in the beginning and not 2,3,and 4 after SSL begins (Link, Internet and Transport layers in the DARPA model are unencrypted). The communication itself (802.11 frame) and the facilities sending it (all contained in layers 2,3), and the meaning (in Layer 4) are never obscured. -KB3VWG PS: Did you try out my web application?

Don, You mentioned a sernario where 802.11 itself is encrypted, I disagree that's legal (see below). I'm also under the impression that, in some cases, the return packet may be a 3rd party communication (if you want to discuss this from Layer 3); but I won't get into that, since I purposely stuck to Layer 1 to formulate my theory. The "communication" here is an 802.11 frame (which happens to contain an Ethernet [802.3] frame, which contains an TCP/IP packet). So, at the 'nitty-gritty' of RF, I'm sending you an 802.11 frame by DSSS or OFDM - by Part 97, I can't obfuscate the 802.11 WLAN frames (so encrypted access points may be a no-no here, but ARRL even says that the code can be 'published' and they believe that solves the closed access point issue - I suppose analogous to someone not knowing the PL tone to transmit, if you will; but I don't 100% agree). I'm 100% aware some stations may disagree with that notion; but as far as I'm concerned, I can sniff 802.11 frames all day, if I can determine the callsign somewhere, tell if it's 802.11, tell the device MACs and that it's an Ethernet frame (even even more, that it's ICMP/TCP/UDP/GRE/IPENCAP/etc.), we're within the scope of the Part 97. -KB3VWG

No, the communication is the entire content of the packet. Again, you can't pick and choose what parts of the law apply and what doesn't. It would be like saying you can do Phone transmissions in the CW portion of the band because it's digital. Your argument continues to try and warp the law as written when it clearly states otherwise. The ARRL has already dropped their argument regarding link layer encryption by using the following overarching rule: *Part 97 : Sec. 97.105 Control operator duties (a) The control operator must ensure the immediate proper operation of the station, regardless of the type of control* This overrides 97.113 as .113 has one of those "except as otherwise specified under this part..." sentences in the subsection preamble. And I've already described a method of authentication using WPA and PKI... some people know it as RADIUS authentication which is good enough for many corporations to authenticate users to their networks. This occurs at a lower level than SSL but higher than link level. This would be just to validate that you are legitimate to access the network. SSL is not a magic bullet. Last week that was proven apparent as many of us have had to patch millions of servers against the Heartbleed vulnerability which involved certain versions of OpenSSL. And if that doesn't scare you, there is always Firesheep. Since authentication should start at the network level and not the session layer due to 97.105 to ensure that you are authorized to transmit and I am authorized to relay your traffic, using LOTW or other higher level means of security does fall subject to 97.113. On Thu, Apr 17, 2014 at 8:38 PM, &lt;lleachii(a)aol.com&gt; wrote:

Unfortunately, none of the wifi security protocols (including WPA with 802.1x) support an authentication-only mode. They all require the traffic to be encrypted as private and unreadable to others. There's also not a whole lot we can do about that since these protocols are baked into the actual wifi chipsets and cannot be modified without a great deal of resources. Since there is no ideal way to both secure layer 2 and remain legal, HamWAN solves this problem at layer 3 by taking advantage of the authentication-only features of IPSec called IPSec(AH) or Authentication Header. When two routers are connected to each other over an RF link, they use the link-local non-routable address space (169.254.0.0/16) on the air so they can speak to just each other. However, those IPs only listen for IPSec(AH) traffic when authenticated with a valid certificate. They can then create a cleartext non-private "VPN" tunnel that allows them to pass traffic for the real network between themselves. Anyone can monitor this traffic, which is good. However, it cannot be successfully altered in transit or spoofed by pirates, which is also good. :) -Cory NQ1E Radio Hacker On Thu, Apr 17, 2014 at 11:53 PM, Don Fanning &lt;don(a)00100100.net&gt; wrote: > (Please trim inclusions from previous messages) > _______________________________________________ > I correct myself. 802.1X would be the lower level protocol/standard and > Radius/Diameter is the layer 7 application. Again this could be intertied > to LDAP or Active Directory for seamless authentication and the potential > to have single sign-on. > > > On Thu, Apr 17, 2014 at 11:29 PM, Don Fanning &lt;don(a)00100100.net&gt; wrote: > > > No, the communication is the entire content of the packet. Again, you > > can't pick and choose what parts of the law apply and what doesn't. It > > would be like saying you can do Phone transmissions in the CW portion of > > the band because it's digital. Your argument continues to try and warp > the > > law as written when it clearly states otherwise. > > > > The ARRL has already dropped their argument regarding link layer > > encryption by using the following overarching rule: > > > > *Part 97 : Sec. 97.105 Control operator duties (a) The control operator > > must ensure the immediate proper operation of the station, regardless of > > the type of control* > > > > This overrides 97.113 as .113 has one of those "except as otherwise > > specified under this part..." sentences in the subsection preamble. > > > > And I've already described a method of authentication using WPA and > PKI... > > some people know it as RADIUS authentication which is good enough for > many > > corporations to authenticate users to their networks. This occurs at a > > lower level than SSL but higher than link level. This would be just to > > validate that you are legitimate to access the network. > > > > SSL is not a magic bullet. Last week that was proven apparent as many of > > us have had to patch millions of servers against the Heartbleed > > vulnerability which involved certain versions of OpenSSL. And if that > > doesn't scare you, there is always Firesheep. > > > > Since authentication should start at the network level and not the > session > > layer due to 97.105 to ensure that you are authorized to transmit and I > am > > authorized to relay your traffic, using LOTW or other higher level means > of > > security does fall subject to 97.113. > > > > > > > > On Thu, Apr 17, 2014 at 8:38 PM, &lt;lleachii(a)aol.com&gt; wrote: > > > >> (Please trim inclusions from previous messages) > >> _______________________________________________ > >> Don, > >> > >> You mentioned a sernario where 802.11 itself is encrypted, I disagree > >> that's legal (see below). I'm also under the impression that, in some > >> cases, the return packet may be a 3rd party communication (if you want > to > >> discuss this from Layer 3); but I won't get into that, since I purposely > >> stuck to Layer 1 to formulate my theory. > >> > >> The "communication" here is an 802.11 frame (which happens to contain an > >> Ethernet [802.3] frame, which contains an TCP/IP packet). So, at the > >> 'nitty-gritty' of RF, I'm sending you an 802.11 frame by DSSS or OFDM - > by > >> Part 97, I can't obfuscate the 802.11 WLAN frames (so encrypted access > >> points may be a no-no here, but ARRL even says that the code can be > >> 'published' and they believe that solves the closed access point issue > - I > >> suppose analogous to someone not knowing the PL tone to transmit, if you > >> will; but I don't 100% agree). > >> > >> I'm 100% aware some stations may disagree with that notion; but as far > as > >> I'm concerned, I can sniff 802.11 frames all day, if I can determine the > >> callsign somewhere, tell if it's 802.11, tell the device MACs and that > it's > >> an Ethernet frame (even even more, that it's > ICMP/TCP/UDP/GRE/IPENCAP/etc.), > >> we're within the scope of the Part 97. > >> > >> > >> -KB3VWG > >> > >> _________________________________________ > >> 44Net mailing list > >> 44Net(a)hamradio.ucsd.edu > >> http://hamradio.ucsd.edu/mailman/listinfo/44net > >> > > > > >

For **** sake, is this list about 44 net, or is it about endless wanking over regulations? My opinion: if you aren't actively developing something and contributing "to the advancement of the radio art" [1], shut up, go register an account on github, and create something of value. Send us the link when you are done. [1]: §97.1 (b) http://www.ecfr.gov/cgi-bin/text-idx?c=ecfr&SID=336ab7469b61ecbfa15086d…

Steve, Actually, I was referring to the passcode that allows someone to access the web application from outside of AMPR (currently '1234' for testing). Of course I don't mind sharing the code that looks at the source IP; and if not 44/8, prompts for a passcode. I used ip2long to convert 44.0.0.1, 44.255.255.255 and the source IP into integers. I then used a 'nested if' statement in the program to test if the source IP was greater than or equal to 44.0.0.1 and less than or equal to 44.255.255.255; if so, it automatically provides the passcode, if not, it prints an additional box, asking for a passcode. { $ip = $_SERVER['REMOTE_ADDR']; $amprtop = "44.0.0.1"; $amprlow = "44.255.255.255"; $longip = ip2long($ip); $rangetop = ip2long($amprtop); $rangelow = ip2long($amprlow); $code = 1234; $access = $_GET['access']; }; // (other portions removed) If (($longip >= $rangetop) && ($longip <= $rangelow)) { echo '<input type="hidden" name="access" value="'.$code.'"></input>'; } else { echo ' Enter NonAMPR Access Code: <input type="text" name="access" value="'.$access.'"></input>'; } -KB3VWG

Sounds like a great idea! Is the VPN service provided by OH7LZB active ? I didn't include it in the main wiki page or as an option to get connected because I thought it was not operational or overloaded. On Mon, Apr 21, 2014 at 2:20 PM, &lt;lleachii(a)aol.com&gt; wrote: > (Please trim inclusions from previous messages) > _______________________________________________ > All, > > I've created a new Wiki page entitled Services at: http://wiki.ampr.org/index.php/Services > > Feel free to add details/information about any service you provide on AMPRNet. It will be good to have a location that notes services that can be found online. > > Also, I'm new to creating Wiki tables, perhaps we should create a second table especially for *NOS nodes. > > > > -KB3VWG >

Beyond creating a manual listing which is easy to read frmom a web page but gets out of date pretty quickly, maybe we could consider a dynamic advertisement mechanism like ZeroConf: http://en.wikipedia.org/wiki/Zero-configuration_networking This would be analogous to what RIP is doing for the AMPR routes but for services. Remote machines would then advertise their available services via Avahi for Linux, Bonjour for OSX, etc. There is also SSDP for WIndows that does a similar function which is supported by many SOHO routers as well. --David

On Tue, Apr 22, 2014 at 2:26 PM, Don Fanning &lt;don(a)00100100.net&gt; wrote: How about DNS SRV records? Does the AMPR DNS robot support that record type? http://en.wikipedia.org/wiki/SRV_record Tom KD7LXL

Not currently; the robot was written long before SRV records were invented. We can look into adding them to its repertoire. I think the underlying database can be modified to accept them. - Brian

Subject says it all. http://www.langelaar.net/projects/jnos2/downloads/linux or https://github.com/mlangelaar/jnos2 Maiko Langelaar / VE4KLM

Hi Maiko.. Any idea what I am doing wrong... This worked last time I Used it.. root@w9bbs:~# rsync -a www.langelaar.net::jnos2 /home/jnos rsync: failed to connect to www.langelaar.net (199.87.159.143): Connection timed out (110) rsync error: error in socket IO (code 10) at clientserver.c(122) [Receiver=3.0.9] root@w9bbs:~# Thanks 73 jerry -----Original Message----- From: 44net-bounces+n9lya=nwcable.net(a)hamradio.ucsd.edu [mailto:44net-bounces+n9lya=nwcable.net@hamradio.ucsd.edu] On Behalf Of Maiko Langelaar Sent: Wednesday, November 5, 2014 11:43 AM To: AMPRNet working group Subject: [44net] JNOS 2.0j.7 is out (Please trim inclusions from previous messages) _______________________________________________ Subject says it all. http://www.langelaar.net/projects/jnos2/downloads/linux or https://github.com/mlangelaar/jnos2 Maiko Langelaar / VE4KLM _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2015.0.5557 / Virus Database: 4189/8517 - Release Date: 11/05/14

Still no go here.. I verified internet connection Looked and no files were indeed updated or downloaded.. Ok.. I will punt for now.. as it's my bed time.. :) Thanks... 73 jerry N9LYA -----Original Message----- From: 44net-bounces+n9lya=nwcable.net(a)hamradio.ucsd.edu [mailto:44net-bounces+n9lya=nwcable.net@hamradio.ucsd.edu] On Behalf Of SP2L Sent: Wednesday, November 5, 2014 5:36 PM To: 44net(a)hamradio.ucsd.edu Subject: Re: [44net] JNOS 2.0j.7 is out (Please trim inclusions from previous messages) _______________________________________________ Hello Jerry et al. For me it worked PERFECTLY. Best regards. --

Thank you so much Maiko. I used rsync for the first time and all went well. The binary compiled with no apparent problems and version JNOS 2.0j.7 appears to be running ok on my Raspberry Pi. Thanks again, your work with jnos2 is truly appreciated. Tony VK7AX gw.vk7ax.ampr.org (44.136.227.2) On 6/11/2014 03:43, Maiko Langelaar wrote:

Maiko; In dirutil.c in function "format_fname_full(file, sbuf, full, n)" you have the function call getdate(&curdate); (around line 386) I think that must be j2getdate(&curdate); instead as curdate is type struct data (see also the jnos header unixtm.h) and the getdata() function in system header time.h uses a string as input and returns a struct. I also added #include "unixtm.h" /* VE3TOK, Nov 14, 2014 */ to dirutil.c format_fname_full(file, sbuf, full, n) FILE *file; struct ffblk *sbuf; int full, n; { struct date curdate; char line_buf[30]; /* for long dirlist */ char cbuf[20]; /* for making line_buf */ if (full) { j2getdate(&curdate); /* Boudewijn (Bob) VE3TOK, Nov14, 2014, changed from *getdate(&curdate); */ etc.... 73, Bob VE3OK

Maiko et al. JNOS 2.0j.7 compiled O.K. on Debian-7.7.0 i686 Runs happily a couple of hours already, Hi! Best regards. Tom - SP2L (ex sp2lob)

Hello Bill et al. Here JNOS 2.0j.7 is happily running little bit over 6 hours but without any crashes or whatsoever - looks O.K. 3 remote and 2 my own nodes connected all the time. Best regards. Tom - SP2L (ex sp2lob)

Hey Bill, Is the entire system crashing and becoming 100% unresponsive or is just JNOS crashing? Do you have any coredumps, back traces, Oopses, etc? Are you running the rip44d daemon by chance? Did you recently patch your machine as part of the usual OS maintenance cycle that might have brought in additional issues? --David KI6ZHD

this is the first time I've attempted rsync and this is what I got in return... rsync -a www.langelaar.net::jnos2 /jnos2 rsync: getaddrinfo: www.langelaar.net 873: Temporary failure in name resolution rsync error: error in socket IO (code 10) at clientserver.c(98) the path is /jnos2 as shown above. Any thoughts? thanks, Don - ve3zda On Fri, Nov 7, 2014 at 2:54 PM, SP2L &lt;SP2L(a)wp.pl&gt; wrote: -- cheers, Don

Hello Don et al. Here it works perfectly: system is Debian-7.7.0 32/64 bit rsync version 3.0.9 protocol version 30 Best regards. Tom - SP2L (ex sp2lob)

Maiko (et al) I was reading through your White Pages information and found where when jnos receives an incoming bulletin addressed to "WP@WW" (and white pages was compiled at time of build) that jnos will capture the white pages haddress information contained in the bulletin. However, I note that several users are not sending these bulletins addressed to "WP@WW" but rather addressed to : WP@USA WP@USBBS WP@WP WP WP@EU .. and so on. Also noting that any FBB and TNOS systems send white pages as a private message to "callsign@haddress" (example "sp kg6baj(a)kg6baj.#nca.ca.usa.noam&quot;) (Also noting that the FBB/TNOS method is what really should be used) So, I was able to see that when those white pages were broadcasted in anything other than "WP@WW", they came in as regular bulletins, and jnos did *NOT* capture any of the data. So, as an *attempted* fix, I created the following "rewrite rules" ------------------------- wp@usa wp@ww r wp@usbbs wp@ww r wp@wp wp@ww r wp wp@ww r wp@kg6baj* wp@ww r wp@* wp@ww r ------------------------- However, these rules immediately caused jnos to crash every time a bulletin was received and attempted to be processed by jnos and my rewrite rules. So, I had to comment out those rules to stabilize jnos again. With this, that leaves all these white-pages broadcast bulletins going around that jnos is really doing nothing with. It would also *appear* that if I have white-pages partners (using command "wpages destination callsign1 callsign2 etc") that if my forward partner is running FBB or TNOS, they will not be able to process my message to them because their system is looking for the format "sp callsign@haddress" but jnos is sending them a "sb wp@ww" So, I thought I should drop this information to you (and others) so that others won't try rewrite rules and start crashing as I did. Any response for resolution is appreciated in advance. Bill Lewis KG6BAJ

That's why I stopped trying to generate any WP traffic a month ago. Maybe we need to get all of the systems on the same page before attempting. On Wed, November 19, 2014 12:12 pm, William Lewis wrote: -- Charles J. Hargrove - N2NOV NYC ARECS/RACES Citywide Radio Officer/Skywarn Coord. NYC-ARECS/RACES Net Mon. @ 8:30PM 147.360/107.2 PL http://www.nyc-arecs.org and http://www.nyc-skywarn.org NY-NBEMS Net Saturdays @ 10AM & USeast-NBEMS Net Wednesdays @ 7PM on 7.036 Mhz USB/1500 hz waterfall spot; Olivia 8/500 check-ins "Information is the oxygen of the modern age. It seeps through the walls topped by barbed wire, it wafts across the electrified borders." - Ronald Reagan "The more corrupt the state, the more it legislates." - Tacitus "Molann an obair an fear" - Irish Saying (The work praises the man.) "No matter how big and powerful government gets, and the many services it provides, it can never take the place of volunteers." - Ronald Reagan

Hi there Is there any distribution of Jnos that wil work on windows XP (32 Bit) ? if yes where can i get it ? and will it work as 44 Nwt router ? i mean will it Encapsulate and decapsulate the 44 Net trafic from the non 44 net and it will ba able to serve as an AMPR gateway ? or i will need to buils a Linux system for that ? Thanks Forward Ronen - 4Z4ZQ http://www.ronen.org ----- Original Message ----- From: "Maiko Langelaar" &lt;maiko(a)pcs.mb.ca&gt; To: "AMPRNet working group" &lt;44net(a)hamradio.ucsd.edu&gt; Sent: Wednesday, November 05, 2014 6:43 PM Subject: [44net] JNOS 2.0j.7 is out

Is it just my system ? I'm seeing many many login attempts as root on telnet. Are they targetting just 44 ? Maiko / VE4KLM

I also use “Fail2Ban” as this can be configured to block an IP after a set number of login failures against a given port or ports. Be warned… bad configuration will lock you out of your own system if you don’t watch out :-) By default, I think it resets the iptables after a set period so not a total failure when you get locked out. Works well for me. Regards Andy Brittain G0HXT g0hxt(a)greatbrittain.co.uk On 8 Jan 2015, at 15:45, Brian &lt;n1uro(a)n1uro.ampr.org&gt; wrote:

2015-01-08 16:37 GMT+01:00 Maiko Langelaar &lt;maiko(a)pcs.mb.ca&gt;ca>: Is it just my system ? Hi Maiko, ... it's normal :( If you can't or wan't use a firewall, change your telnet/ssh tcp port to a non standard one. Brute Force Attacks are 99% script-based and target standard udp & tcp port ( telnet -> 23/tcp, ssh -> 22/tcp). E. -- Enrico Ardizzoni / IW4DZV

On Tue, Jun 23, 2015 at 5:51 PM, Maiko Langelaar &lt;maiko(a)pcs.mb.ca&gt; wrote: This kind of thing is expected. It is the Internet, after all. This is exactly what the UCSD group studies with 44net. These scans are present on all of 44/8. Stuff addressed for you is forwarded to you. Everything that's unallocated is sent to the UCSD group for research. Tom KD7LXL

Matter of fact is that he has only the first address of his subnet registered in the dns so he should only get Internet garbage for that address from ucsd. Bob

This is nothing new. Hi all at GB7CIP for years the subnets hosted at it's gateway. Has all addresses scanned for open ports via the ipip protocol 4 with non 44net source address to 44net address. These are continous.. All are blocked at this gateway, aS security policy here does not allow Non 44net direct access. this is juse one current example which is a valid dns entry in this case 12:57:24.052561 IP 169.228.66.251 > 192.168.#.#: IP 85.25.103.50.34680 > 44.131.244.31.8098: Flags [S], seq 2571617267, win 3928, length 0 (ipip-proto-4) Even entries with now DNS entries. 73 de Paul g4apl

SIP over AMPRnet is something that I would like to see as we can use Asterisk to interface to a radio as the Codec2 from the FreeDV world is already one that can be incorporated into Asterisk. Imagine, a ham only intercom system using 9k6 SIP packets in case the local phone and cell system goes down as happened in areas of NYC, LI and NJ from Hurricane Sandy. -- Charles J. Hargrove - N2NOV NYC ARECS/RACES Citywide Radio Officer/Skywarn Coord. NYC-ARECS/RACES Net Mon. @ 8:30PM 147.360/107.2 PL or 441.100/136.5 PL http://www.nyc-arecs.org and http://www.nyc-skywarn.org NY-NBEMS Net Saturdays @ 10AM & USeast-NBEMS Net Wednesdays @ 7PM on 7.036 Mhz USB/1500 hz waterfall spot; Olivia 8/500 check-ins "Information is the oxygen of the modern age. It seeps through the walls topped by barbed wire, it wafts across the electrified borders." - Ronald Reagan "The more corrupt the state, the more it legislates." - Tacitus "Molann an obair an fear" - Irish Saying (The work praises the man.) "No matter how big and powerful government gets, and the many services it provides, it can never take the place of volunteers." - Ronald Reagan

There really is no need to get ENUM or DNS SRV records involved. ENUM is a useless shim that redirects landline numbers to SIP (or IAX) addresses. DNS SRV records are only really necessary for failover or if your services are hosted at another location. (I know, thats a bit over-simplified. Keep going..) Any softphone could dial a URI such as sip://ke4rap@ke4rap.ampr.org. I can easily build an extension on my PBX to place a call to sip://ke4rap@ke4rap.ampr.org when I dial any numeric string I desire from a numeric-only endpoint (269 for example). This numeric-to-URI translation for numeric endpoints easily takes place in the dialplan on the sending end, and should not rely on some new set of numeric addresses to further complicate things. On the receive end, a call to ke4rap@ on my PBX (ke4rap.ampr.org) could be routed to any sort of endpoint, numeric or otherwise. Now supposed AA4AA would rather not run a PBX? Well, if some nice guy wants to set up a shared system, we only need to know AA4AA is hosted on KB3AAs PBX or some shared AMPR PBX and can be reached at SIP://AA4AA@KB3AA.ampr.org or sip://AA4AA@asterisk1.ampr.org. This is the very basis of peer-to-peer URI calling. All you really need is a standard DNS lookup and some idea who you are calling. This also exists RIGHT NOW. If i know CALLSIGN has a PBX on here and is set up in DNS, I could call him right now at CALLSIGN(a)CALLSIGN.ampr.org and the call will route. No other acronyms other than DNS need to be harmed for this to take place. :) Danny Messano KE4RAP Sent from my iPhone > On Apr 22, 2014, at 10:32 PM, Don Fanning &lt;don(a)00100100.net&gt; wrote: > > (Please trim inclusions from previous messages) > _______________________________________________ > Should be quite doable provided there isn't lots of firewalling or natting > involved. If not this protocol, IAX2 within Asterisk for which there are > already ham radio adaptations made to it (ie: app_rpt and other pieces) can > easily make the connection. Some sort of e164/enum lookup based on > callsigns would also be beneficial but that also requires DNS hackery > [something to be added along with SRV records?] > > >> On Tue, Apr 22, 2014 at 3:51 PM, Eric Fort &lt;eric.fort(a)gmail.com&gt; wrote: >> >> (Please trim inclusions from previous messages) >> _______________________________________________ >> actually making SIP work really well over amprnet would be cool. >> >> >>> On Tue, Apr 22, 2014 at 2:49 PM, Tom Hayward &lt;esarfl(a)gmail.com&gt; wrote: >>> >>> (Please trim inclusions from previous messages) >>> _______________________________________________ >>>> On Tue, Apr 22, 2014 at 2:26 PM, Don Fanning &lt;don(a)00100100.net&gt; wrote: >>>> (Please trim inclusions from previous messages) >>>> _______________________________________________ >>>> ZeroConf depends on Multicast which doesn't work well over >> tunnels/VPN's >>>> unless specifically configured for such. >>> >>> How about DNS SRV records? Does the AMPR DNS robot support that record >>> type? >>> >>> http://en.wikipedia.org/wiki/SRV_record >>> >>> Tom KD7LXL >>> _________________________________________ >>> 44Net mailing list >>> 44Net(a)hamradio.ucsd.edu >>> http://hamradio.ucsd.edu/mailman/listinfo/44net >>

But far from being required. If you're putting the services in obvious locations there is no need to discover anything. For example, if the SIP services for ke4rap.ampr.org were hosted at ke4rappbx.ampr.org, and we're working off the callsign(a)callsign.ampr.org schema, a SRV record (and lookup) is necessary, obviously, for the call to be delivered. But, I don't need a SRV record to tell the world I am hosting SIP at ke4rap.ampr.org when that's the de facto destination for a call for ke4rap. Sent from my iPhone > On Apr 23, 2014, at 1:07 AM, K7VE - John &lt;k7ve(a)k7ve.org&gt; wrote: > > (Please trim inclusions from previous messages) > _______________________________________________ > SRV records help with discovery. > > ________________________________ > John D. Hays > K7VE > PO Box 1223, Edmonds, WA 98020-1223 > > > >> On Tue, Apr 22, 2014 at 9:49 PM, Danny Messano &lt;drmessano(a)gmail.com&gt; wrote: >> (Please trim inclusions from previous messages) >> _______________________________________________ >> There really is no need to get ENUM or DNS SRV records involved. >> >> ENUM is a useless shim that redirects landline numbers to SIP (or IAX) >> addresses. DNS SRV records are only really necessary for failover or >> if your services are hosted at another location. (I know, thats a bit >> over-simplified. Keep going..) >> >> Any softphone could dial a URI such as sip://ke4rap@ke4rap.ampr.org. >> I can easily build an extension on my PBX to place a call to >> sip://ke4rap@ke4rap.ampr.org when I dial any numeric string I desire >> from a numeric-only endpoint (269 for example). This numeric-to-URI >> translation for numeric endpoints easily takes place in the dialplan >> on the sending end, and should not rely on some new set of numeric >> addresses to further complicate things. >> >> On the receive end, a call to ke4rap@ on my PBX (ke4rap.ampr.org) >> could be routed to any sort of endpoint, numeric or otherwise. >> >> Now supposed AA4AA would rather not run a PBX? Well, if some nice guy >> wants to set up a shared system, we only need to know AA4AA is hosted >> on KB3AAs PBX or some shared AMPR PBX and can be reached at >> SIP://AA4AA@KB3AA.ampr.org or sip://AA4AA@asterisk1.ampr.org. >> >> This is the very basis of peer-to-peer URI calling. All you really >> need is a standard DNS lookup and some idea who you are calling. >> >> This also exists RIGHT NOW. If i know CALLSIGN has a PBX on here and >> is set up in DNS, I could call him right now at >> CALLSIGN(a)CALLSIGN.ampr.org and the call will route. No other acronyms >> other than DNS need to be harmed for this to take place. :) >> >> Danny Messano >> KE4RAP >> >> Sent from my iPhone >> >>> On Apr 22, 2014, at 10:32 PM, Don Fanning &lt;don(a)00100100.net&gt; wrote: >>> >>> (Please trim inclusions from previous messages) >>> _______________________________________________ >>> Should be quite doable provided there isn't lots of firewalling or natting >>> involved. If not this protocol, IAX2 within Asterisk for which there are >>> already ham radio adaptations made to it (ie: app_rpt and other pieces) can >>> easily make the connection. Some sort of e164/enum lookup based on >>> callsigns would also be beneficial but that also requires DNS hackery >>> [something to be added along with SRV records?] >>> >>> >>>> On Tue, Apr 22, 2014 at 3:51 PM, Eric Fort &lt;eric.fort(a)gmail.com&gt; wrote: >>>> >>>> (Please trim inclusions from previous messages) >>>> _______________________________________________ >>>> actually making SIP work really well over amprnet would be cool. >>>> >>>> >>>>> On Tue, Apr 22, 2014 at 2:49 PM, Tom Hayward &lt;esarfl(a)gmail.com&gt; wrote: >>>>> >>>>> (Please trim inclusions from previous messages) >>>>> _______________________________________________ >>>>>> On Tue, Apr 22, 2014 at 2:26 PM, Don Fanning &lt;don(a)00100100.net&gt; wrote: >>>>>> (Please trim inclusions from previous messages) >>>>>> _______________________________________________ >>>>>> ZeroConf depends on Multicast which doesn't work well over >>>> tunnels/VPN's >>>>>> unless specifically configured for such. >>>>> >>>>> How about DNS SRV records? Does the AMPR DNS robot support that record >>>>> type? >>>>> >>>>> http://en.wikipedia.org/wiki/SRV_record >>>>> >>>>> Tom KD7LXL >>>>> _________________________________________ >>>>> 44Net mailing list >>>>> 44Net(a)hamradio.ucsd.edu >>>>> http://hamradio.ucsd.edu/mailman/listinfo/44net >>>>

That's ENUM, not DNS SRV, and again, not necessary. I know of very few software SIP clients that don't allow SIP URI dialing. No need for numerics whatsoever. I can dial alphanumeric user@host from any number of clients. I also addressed the numeric hardware endpoints, such as desk phones and ATAs. I have "translated" numeric dialing to SIP URI dialing for years using the Asterisk dialplan. exten => 234,1,Dial(SIP/ke4rap(a)ke4rap.ampr.org). We don't NEED and should absolutely NOT develop some horrible kludge of a numeric schema for number <> callsign translation. If I have numeric-only endpoints I can address those in MY dialplan. Ultimately on the wire calls should be going peer-to-peer with user@host SIP URI's and only require DNS A and CNAME's for routing. DM

AFAIK SIP assumes by design that user@host has its SIP server running on "host". That what an URI is ment to do and not doing so actually seams ilogical to me. -----Original Message----- From: 44net-bounces+marius=yo2loj.ro(a)hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Antonio Querubin Sent: Wednesday, April 23, 2014 15:42 To: AMPRNet working group Subject: Re: [44net] New Wiki Page - Services ... No this has nothing to do with ENUM. In general, one cannot absolutely assume name@domain is reachable at a SIP server running on a host named 'domain'. That's inflexible and is like assuming only host 'domain' will accept email for name@domain. There may not even be an actual host named 'domain' or if there is, it may not be running SIP. Ignoring SRV RRs also means your SIP client/proxy or SBC wouldn't be taking advantage of the resiliency provided by alternate target servers. Antonio Querubin ...

What relevance does any of this tangential discussion have to the 44/8 network? It seems to be that discussion about how SIP works, or what a URI is, or what SRV records are, or how service discovery can be realized on a global IP network would be relevant to *any* IP network. Surely there are more appropriate forums for such discussion. Surely such forums have a deeper and broader base of experience more equipped to field these concerns. Surely, if these problems can be solved, the internet at large should benefit. Perhaps I do not understand the point of 44net. Is the point not to build an RF network that is part of the internet, but rather to discuss how hams might build an isolated network for their own needs while squatting on a full 0.4% of the IPv4 address space for no reason at all? Let me put it more bluntly: if what you are discussing could work on 10/8 just as well as it could work on 44/8, then please consider that maybe your discussion isn't very inspired. Having a full /8 block of potentially globally routable IP addressing space available to the amateur radio service is a unique opportunity, one that could not feasibly be purchased today, and one that has been largely squandered thus far. If you don't immediately understand what unique opportunity 44/8 presents, then perhaps you are not a very good network engineer and you should consider talking less and listening more carefully.

And what is wrong in discussing how to approach SIP in this environment? Or should we just stay with discussions "Aaaah, I have an unknown ping to my gateway". And yes, there is a potentially routeable /8 block and I don't unterstand that unique opportunity: the oportunity to do nothing by not discussing anything. Everytime something gets moving, there is opposition. Whit no exceptions. Now, since EVERYTHING we discuss here works on 10/8 except global routing. So lets drop it and just sit back and relax... Marius, YO2LOJ

On Wed, 23 Apr 2014, Danny Messano wrote: And that's fine for p2p SIP. What started this part of the thread was someone requesting the option of adding SRV RRs to the ampr.org zone. I had also asked for this quite some time ago and I am glad that flexibility is now in the portal. Antonio Querubin e-mail: tony(a)lavanauts.org xmpp: antonioquerubin(a)gmail.com