All,
I've added a new tool that I'd like you to test. This web application should provide the registration code required by APRS software suites. In order to use it, you must browse to:
http://kb3vwg-010.ampr.org/tools/aprscode or http://44.60.44.10/tools/aprscode
If you're on AMPRNet, you should be able to enter the callsign and look up the registration code. If you access it from outside of AMPRNet, you will be prompted for an access code (1234).
Please let me know how it works
73,
KB3VWG
On Thu, Apr 17, 2014 at 8:35 AM, lleachii@aol.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ All,
I've added a new tool that I'd like you to test. This web application should provide the registration code required by APRS software suites. In order to use it, you must browse to:
http://kb3vwg-010.ampr.org/tools/aprscode or http://44.60.44.10/tools/aprscode
If you're on AMPRNet, you should be able to enter the callsign and look up the registration code. If you access it from outside of AMPRNet, you will be prompted for an access code (1234).
Please let me know how it works
It's poor design to allow authorization via source address or low-entropy password with no authentication. I was just able to generate a passcode for KB3VWG, but I'm not KB3VWG. I certainly don't want you handing out passcodes for KD7LXL. I already have mine memorized, and no one else needs it.
A more prudent, yet still automated, scheme would be to authenticate with a certificate. For example, a Logbook of the World certificate from the ARRL contains your callsign, and is only issued by the ARRL after verifying your identity. A web app using SSL client verification could read the callsign from this certificate and return the APRS-IS passcode for that callsign, and only that callsign. That is proper authentication.
You might ask, why go through all that trouble when the APRS-IS passcode is generated with a public algorithm? I agree with you there. It would be prudent to implement better authentication on APRS-IS. I have done so on the APRS server I manage: http://44.24.242.23:14501/ When connecting to the SSL ports, the server will read your callsign out of a Logbook of the World certificate. If your client requests it, the server will use only the authentication component of SSL, disabling the encryption (important if you're connecting via RF). Application support for this scheme is low right now (I've done it with APRSDroid, and Xastir+stunnel), but I expect adoption to increase.
Tom KD7LXL
I've added a new tool that I'd like you to test. This web application should provide the registration code required by APRS software suites. In order to use it, you must browse to:
http://kb3vwg-010.ampr.org/tools/aprscode or http://44.60.44.10/tools/aprscode
If you're on AMPRNet, you should be able to enter the callsign and look up the registration code. If you access it from outside of AMPRNet, you will be prompted for an access code (1234).
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.
All,
Please be advised, all the current ways of obtaining the APRS codes function in a less secure manner than this.
Also, I have a different opinion of HTTPS/SSL use on Ham Radio (I'm of the opinion it is permitted), that can be discussed in another forum/topic.
As other stations noted, someone can simply impersonate a station and obtain the registration code, at least here, that someone must be on AMPR to access the service. Next, I do not intend to provide the access code, meaning only those on AMPR could generate "recovery codes." I simply added the access code feature in case I was not at my station when I needed the service (and since it was my first PHP script, to simply see if I still had my "programming touch" from the C++ days).
Lastly, the software that I based the application on is public and could be installed and ran by anyone with a Linux machine.
I considered that BEFORE I wrote the application.
-KB3VWG
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
On Thu, 17 Apr 2014, lleachii@aol.com wrote:
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.
That's not true, the CA does not have to be online at the moment of validation. [1]
You just need to hold a copy of the CA's certificate (which contains the certificate's public key). The actual validation is then with a bit of cryptography - but you don't need to ask the CA for its opinion at that point.
[1] Unless you wish to use OSCP for a real-time check for revocation of a valid certificate, for example, in the case an amateur radio license would have been revoked, or the CA would have accidentally granted a cert to a non-ham. Alternative to this is that the CA can publish a revocation list, which can be downloaded and then used off-line to check for revocation status without asking the CA at the moment of verification.
- Hessu
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
Hessu,
My apologies, you are correct; though I was in fact making a reference to verifying the real-time status of the cert.
-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 requesthttps://code.google.com/p/chromium/issues/detail?id=58831#c22for 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 documenthttps://www.hamwan.org/t/tiki-index.php?page=SSL+without+Encryption&structure=HamWANon 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, lleachii@aol.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ Hessu,
My apologies, you are correct; though I was in fact making a reference to verifying the real-time status of the cert.
-KB3VWG _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Actually, the point of the topic was to inform me if the application worked as I described.
Since I noted that I'm of the opinion that encryption (in some cases) is allowed on Ham Radio, that was a non-issue.
US Part 97 never says "encryption is prohibited," it says:
"RTTY and data emissions using unspecified digital codes must not be transmitted for the purpose of obscuring the meaning of any communication."
What is a communication??? 47 U.S. Code § 153(40) Radio communication: 'The term “radio communication” or “communication by radio” means the transmission by radio of writing, signs, signals, pictures, and sounds of all kinds, including all instrumentalities, facilities, apparatus, and services (among other things, the receipt, forwarding, and delivery of communications) incidental to such transmission.'
You may wish to look through the list of digital codes specified in Part 97 and use Wireshark to sniff SSL packets...you may find you can read the HTTP GET command, source, destination, requests, requests to exchange, etc. in plain English, ASCII is exempt the last time I checked. Even on the 802.11 level, source, destination and acknowledgments can be read. I don't want to enter a large debate, but I wouldn't suggest seeking a rule-making on it either.
:)
-KB3VWG
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, lleachii@aol.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ You may wish to look through the list of digital codes specified in Part 97 and use Wireshark to sniff SSL packets...you may find you can read the HTTP GET command, source, destination, requests, requests to exchange, etc. in plain English, ASCII is exempt the last time I checked. Even on the 802.11 level, source, destination and acknowledgments can be read. I don't want to enter a large debate, but I wouldn't suggest seeking a rule-making on it either.
More interesting to the discussion of part 97 referencing encryption is not the definition of communication but the meaning of "meaning" as it applies to the packet I'm handed to pass along further down the network. If I get a packet composed of a string of 1's & 0's, say 0011001101001011110011010010...... it means to me exactly 0011001101001011110011010010..... and so long as I have done nothing to obscure the meaning of that string of bits I don't know that I ought need care what the upper 4 layers of the osi stack do with such upon recipt or transmission. Ultimately what does "meaning" mean. that seems to me to be where the meat is in this.
Eric
On Thu, Apr 17, 2014 at 4:37 PM, lleachii@aol.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ Actually, the point of the topic was to inform me if the application worked as I described.
Since I noted that I'm of the opinion that encryption (in some cases) is allowed on Ham Radio, that was a non-issue.
US Part 97 never says "encryption is prohibited," it says:
"RTTY and data emissions using unspecified digital codes must not be transmitted for the purpose of obscuring the meaning of any communication."
What is a communication??? 47 U.S. Code § 153(40) Radio communication: 'The term "radio communication" or "communication by radio" means the transmission by radio of writing, signs, signals, pictures, and sounds of all kinds, including all instrumentalities, facilities, apparatus, and services (among other things, the receipt, forwarding, and delivery of communications) incidental to such transmission.'
You may wish to look through the list of digital codes specified in Part 97 and use Wireshark to sniff SSL packets...you may find you can read the HTTP GET command, source, destination, requests, requests to exchange, etc. in plain English, ASCII is exempt the last time I checked. Even on the 802.11 level, source, destination and acknowledgments can be read. I don't want to enter a large debate, but I wouldn't suggest seeking a rule-making on it either.
:)
-KB3VWG _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
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?
That's not quite true. The FCC regulates how you use the spectrum. The OSI model is just an explanation of how different pieces interact with each other. At the end of the day, it still travels over licensed spectrum. Which is why you can't use ham bands for news gathering. Or the spectrum itself for profitable pursuits. Or for broadcasting music programs. Certainly you can argue that streaming digital copies of Metallica over amateur licensed bands doesn't constitute broadcasting nor music but that doesn't change the meaning of the law. I'm sure the NAB and the RIAA would want the pounds of flesh from those who dare them... and they have alot of *money*pull*money* with the FCC.
So to say that the FCC doesn't have power to regulate communication content is a falsehood.
Back to encryption: "No amateur station shall transmit [...] messages encoded for the purpose of obscuring their meaning, except as otherwise provided herein; obscene or indecent words or language; or false or deceptive messages, signals or identification." Part 97.113
The argument of SSL is that it is necessary for identification (authentication) of the user. Well, it already says that saying I'm someone else is already illegal. But it also says that it's illegal to obscure the message that identifies me. This comes from the line of thinking that people need to be able to identify who is making the transmission. IP addressing already accomplishes this. Anything extra layer of authentication becomes an obscure message as you've already accomplished it at the 44.x.x.x level.
But let's take it to a lower level. Let's say I hop on HamWAN and instead of using my assigned IP space, I use one of the IP's in the pool. At which point I'm using the HamWAN's ip space and their callsign. But if I was unlicensed, I would be a pirate. The way to mitigate this is to use WEP or even take it to the layer of WPA with TKIP or even WPA with certificates (Enterprise TKIP). Then I would be identifying myself by using an PKI certificate as well as potentially handshaking with my callsign to the HamWAN callsign. The reason for this is to keep within the rules for maintaining proper access and control of your station (in this case HamWAN's). Kerberos could certainly be used as part of the authentication scheme (similar to remote management of a satellite or repeater system) but there should be no need for any kind of authentication or encryption at any higher level except for remote management of the network hardware. SSL being layer 5 and up would still be considered content and thusly against the rules. But one can also argue that using even WEP constitutes a violation.
It's one thing to say it's a grey area. It's another to try and bend the law's plain meaning into your own advantage because you don't want to do the legwork.
Personally, I think it will take another RM similar to the EMCOMM one last year to change this properly as in the end I do agree with all of you that in the digital age there should be authentication of transmissions at all layers of the model. But the rules, as written today, only provides for the most basic means of identification.
On Thu, Apr 17, 2014 at 5:45 PM, lleachii@aol.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ 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?
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
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
KB3VWG et al,
The FCC disagrees with your statements on encryption. The concern is regarding the ability of others to receive your transmission's content. A PL tone does not block the ability for an external party to receive the message. Quoted from FCC DA13-1918, released on 18 September 2013: "Section 97.113 is intended to help maintain the non-commercial character of the amateur radio service by prohibiting certain types of transmissions. The primary protection against exploitation of the amateur service and the enforcement mechanism in the amateur service is its self-regulating character. [...] amateur stations must be capable of understanding the communications of other amateur stations. The content of messages that are encoded, however, are known only to those stations that have the code used to encode the message. In the case of encrypted messages, the message content is known only to stations having the encryption algorithm or key." It is reasonable to believe that if a third party cannot reasonably determine the contents of a message (eg, more than just metadata), that transmission is in violation.
Also a few posts prior, KB3VWG stated "US Part 97 never says 'encryption is prohibited'". While this is true, it is unwise to interpret that loosely. The phrase "prohibition on encryption" is used multiple times in FCC order DA13-1918. While this is not as unequivocal as a statement in CFRs, it does provide insight to their intent of part 97, and we should act accordingly.
Note that authentication mechanisms are not part of the identifying character of a transmission's nature. In the same petition, the ARRL submitted comments that stated "the ARRL has previously advised members, following discussions with Commission Enforcement Bureau and Wireless Bureau staff, that encoding exclusively for authentication purposes does not violate Section 97.113(a)(4)". These remarks were not addressed in the FCC's order, but other parts of the comment were referenced and quoted directly. We should continue to operate with the understanding that the use of encryption for the purpose of authentication is permissible and certainly not a gray area.
Luckily the FCC recognizes that this ban on encryption (and other "impediment"s to hams) is an issue suitable to be resolved in administration rather than legislation. I remain hopeful that this may be resolved in petitions. As always, I am not a lawyer, you should not act on my opinion, and you are wise to completely ignore my message.
Cheers, K0RET
On Thu, Apr 17, 2014 at 10:38 PM, lleachii@aol.com 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@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
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, lleachii@aol.com 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@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
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 don@00100100.net 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, lleachii@aol.com 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@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
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 don@00100100.net 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 don@00100100.net 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, lleachii@aol.com 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@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On Fri, Apr 18, 2014 at 12:35 AM, Cory (NQ1E) cory@nq1e.hm wrote:
(Please trim inclusions from previous messages) _______________________________________________ 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.
However if rule 97.105 applies, this shouldn't matter as it would be deemed necessary to "maintain control of your station".
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. :)
Totally get this idea and it's not bad at all as it lends to transparency. AH would be the minimum required for authentication for 97.105 but stacking SSL for websites probably would run contrary to the 97.113 rule.
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=336ab7469b61ecbfa15086db...
All,
Ok, ok, ok.
I mentioned before that I'm sure there's folk that won't agree with me. I simply choose not to hop around all the layers of the Internet model when assembling a cohesive understanding of the rule; and I don't think a non-technical radio amateur would be expected to bounce around the OSI/DARPA model to gather an understanding either.
Fair enough that it would be ideal to have another form of encryption, but I agree with NQ1E when he says that only IPSec(AH) makes Layer 1 and 2 remain readable. A unified captive portal authentication is also another option (Layer 7 authentication); but under some points-of-view, the portal could not be SSL. My suggestion of SSL was not to solve an access issue, I simply said I don't agree with the common point-of-view that it's prohibited outright. To prove that point, I use a Layer-1-first method to interpret the rule, just as is done for all other modes (e.g. in voice over FM, layer 1 is the FM carrier and the voice is layer 2, neither of the first 2 layers can be obscured).
Once again, I simply choose not to bounce around the OSI/DARPA model to gain an understanding, so I stick to Layer 1 first. The fact remains, at some point, if security is implemented, the traffic is obscured. Part 97 plainly read would led one to at least begin building their security implementation starting with Layer 1 unencrypted and Layer 2 should not be obscured (i.e. the 802.11 frame and the 802.3 frame).
-KB3VWG
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
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
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, lleachii@aol.com 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
On Tue, Apr 22, 2014 at 11:36 AM, Neil Johnson neil.johnson@erudicon.com wrote:
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.
Not sure how you concluded this. It's working fine from here.
It would only take a few minutes to set up and test yourself.
Tom KD7LXL
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
ZeroConf depends on Multicast which doesn't work well over tunnels/VPN's unless specifically configured for such.
On Tue, Apr 22, 2014 at 2:02 PM, David Ranch amprgw@trinnet.net wrote:
(Please trim inclusions from previous messages) _______________________________________________
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
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On Tue, Apr 22, 2014 at 2:26 PM, Don Fanning don@00100100.net 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
actually making SIP work really well over amprnet would be cool.
On Tue, Apr 22, 2014 at 2:49 PM, Tom Hayward esarfl@gmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Tue, Apr 22, 2014 at 2:26 PM, Don Fanning don@00100100.net 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@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On Tue, Apr 22, 2014 at 2:49 PM, Tom Hayward esarfl@gmail.com wrote:
How about DNS SRV records? Does the AMPR DNS robot support that record type?
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
On 23 Apr 2014, at 00:35, Brian Kantor Brian@UCSD.Edu wrote:
(Please trim inclusions from previous messages) _______________________________________________
On Tue, Apr 22, 2014 at 2:49 PM, Tom Hayward esarfl@gmail.com wrote:
How about DNS SRV records? Does the AMPR DNS robot support that record type?
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.
The database is already setup to accept SRV records and the new portal DNS interface allows them (check it out and see for yourself).
We are actively working on getting this section of the portal live and hope to make it so very soon (weeks not months).
Chris
Subject says it all.
http://www.langelaar.net/projects/jnos2/downloads/linux
or
https://github.com/mlangelaar/jnos2
Maiko Langelaar / VE4KLM
Maiko.
GOOD NEWS, indeed! Thank you.
Best regards. Tom - SP2L (ex sp2lob)
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@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@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
Hello Jerry et al.
For me it worked PERFECTLY.
Best regards. --
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@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@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. --
Fixed.. Got it,, Thanks knowing it worked for you,, Made me remember my firewall is self-learning and tends to get extreme.. My New firewall.. CSF was blocking it.. Will add to the list of good IPs.. :)
Had to get extreme to keep the Chinese out...:)_
73 Jerry n9lya
-----Original Message----- From: Jerry Kutche [mailto:n9lya@nwcable.net] Sent: Wednesday, November 5, 2014 5:40 PM To: 'AMPRNet working group' Subject: RE: [44net] JNOS 2.0j.7 is out
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@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@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:
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@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On Wed, 5 Nov 2014 10:43:29 -0600 (CST), Maiko Langelaar maiko@pcs.mb.ca wrote:
Subject says it all.
http://www.langelaar.net/projects/jnos2/downloads/linux
or
https://github.com/mlangelaar/jnos2
Maiko Langelaar / VE4KLM
I don't know how much you care about portability at this point but you might want to consider migrating the code more toward current C standard, like either C99 or even C11 to keep up with the compilers on the platform. For example, use <limits.h> instead of <values.h> and replacing macros like MAXLONG with LONG_MAX, MAXSHORT with SHRT_MAX, etc.
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
Subject says it all.
http://www.langelaar.net/projects/jnos2/downloads/linux
or
https://github.com/mlangelaar/jnos2
Maiko Langelaar / VE4KLM
Sorry wrong list..
Bob VE3TOK
On 14-11-15 04:19 AM, Boudewijn (Bob) Tenty 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
Subject says it all.
http://www.langelaar.net/projects/jnos2/downloads/linux
or
https://github.com/mlangelaar/jnos2
Maiko Langelaar / VE4KLM
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)
This is odd...
Just one day after Maiko announced that JNOS version 2.0j.7 is out, my system has started crashing several times a day, every day.
Except... I haven't upgraded yet.
Is there something with the new version that maybe is causing crashes with link partners ??
Anyone else started having daily crashes or is it just me?
Bill KG6BAJ
At 02:45 AM 11/07/14, you wrote:
(Please trim inclusions from previous messages) _______________________________________________ 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)
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
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)
Running since the Oct 03, 2014 being rock steady :)
gus
22:53:41 - allocating maximum of 4 Axip (axudp + axip) devices 22:53:41 - allocating maximum of 4 dynamic gateways for routes 22:53:41 - using new [tun0] device 22:53:41 - tun_rx - listening for packets 22:53:42 - INP scheduler is active 22:53:42 - JNOS 2.0j.7 (Linux) (i0ojj.ampr.org gateway) was started
----------- On 11/07/2014 05:21 PM, SP2L wrote:
(Please trim inclusions from previous messages) _______________________________________________ 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)
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
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 odd...
Just one day after Maiko announced that JNOS version 2.0j.7 is out, my system has started crashing several times a day, every day.
Except... I haven't upgraded yet.
Is there something with the new version that maybe is causing crashes with link partners ??
Anyone else started having daily crashes or is it just me?
Hello Maiko et al.
Adding to JNOS 2.0j.7 functionality to change type of logging style was VERY BRIGHT IDEA, indeed!
Thank you very much for that!
Best regards. Tom - SP2L (ex sp2lob)
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 SP2L@wp.pl wrote:
(Please trim inclusions from previous messages) _______________________________________________ Hello Maiko et al.
Adding to JNOS 2.0j.7 functionality to change type of logging style was VERY BRIGHT IDEA, indeed!
Thank you very much for that!
Best regards. Tom - SP2L (ex sp2lob)
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
That seems to be a dns error Don.
You can also download a tar ball of it..
http://www.langelaar.net/projects/jnos2/downloads/linux/jnos2.0j.7.tar.gz
I discovered that the latest rsync client has a bug as it is fine with Ubuntu 12.04 but it doesn't work with version 14.04 (rsync 3.1.0) if the server runs rsync 3.0.9-12 and newer rsync clients as 3.0.9-12
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver] rsync error: error in rsync protocol data stream (code 12) at io.c(226) [Receiver=3.1.0]
That problem is still not resolved if I search for it.
Bob VE3TOK
On 14-11-07 07:32 PM, Don Moore wrote:
(Please trim inclusions from previous messages) _______________________________________________ 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 SP2L@wp.pl wrote:
(Please trim inclusions from previous messages) _______________________________________________ Hello Maiko et al.
Adding to JNOS 2.0j.7 functionality to change type of logging style was VERY BRIGHT IDEA, indeed!
Thank you very much for that!
Best regards. Tom - SP2L (ex sp2lob)
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
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... Just a note to let you know that 2.0j.7 compiled with no errors on me Rasberry Pi and has been running for about a week with no issues at all. Good job my man! j. - ve7ass/yvrass
On 14-11-05 08:43 AM, Maiko Langelaar wrote:
(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@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
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@kg6baj.#nca.ca.usa.noam")
(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
I think you will find that FBB actions White Pages Updates database as Personal Messages to the WP process running at their partner systems
SP WP @ (Remote BBS)
all WP as Bulletins are deleted from the network in our reject.sys files.
Not as you have detailed below. Or the newer system are interpreting the White Pages database update
Yes the FBB servers note the entries in the R:LINES as the Bulletins and SP message pass around the network normally as Guessing G I think... No doubt and expert in the original WhitePages Database processing has further comments, re the current implementations. Paul g4apl
In message 6.0.0.22.2.20141119085258.01c9a458@mail.n1oes.org, William Lewis kg6baj@n1oes.org writes
(Please trim inclusions from previous messages) _______________________________________________ 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@kg6baj.#nca.ca.usa.noam")
(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:
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@kg6baj.#nca.ca.usa.noam")
(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
-- 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
SNOS sends an receives WP@WW as bulletins. Always has and always will. It can also process WP updates to targeted regions such as WP@USA. Bulletin subject line is always: WP Update
David Warner, W7SZS
On 11/19/2014 12:01 PM, Charles Hargrove wrote:
(Please trim inclusions from previous messages) _______________________________________________ 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:
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@kg6baj.#nca.ca.usa.noam")
(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
-- 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
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
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" maiko@pcs.mb.ca To: "AMPRNet working group" 44net@hamradio.ucsd.edu Sent: Wednesday, November 05, 2014 6:43 PM 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@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Hello Ronen.
I think that all you need is to poke around the link supplied by Maiko:
http://www.langelaar.net/projects/jnos2/downloads
You may find here what most probably will suit your needs.
Best regards.
Is it just my system ?
I'm seeing many many login attempts as root on telnet.
Are they targetting just 44 ?
Maiko / VE4KLM
Maiko;
On Thu, 2015-01-08 at 09:37 -0600, Maiko Langelaar wrote:
Is it just my system ?
Would it comfort you if I said it was just your system? If so, then yes ;-)
I'm seeing many many login attempts as root on telnet. Are they targetting just 44 ?
I see them pretty consistently on my system as well, and those I remote admin. The tool iptables is your friend here.
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@greatbrittain.co.uk
On 8 Jan 2015, at 15:45, Brian n1uro@n1uro.ampr.org wrote:
(Please trim inclusions from previous messages) _______________________________________________ Maiko;
On Thu, 2015-01-08 at 09:37 -0600, Maiko Langelaar wrote:
Is it just my system ?
Would it comfort you if I said it was just your system? If so, then yes ;-)
I'm seeing many many login attempts as root on telnet. Are they targetting just 44 ?
I see them pretty consistently on my system as well, and those I remote admin. The tool iptables is your friend here.
-- If Microsoft intended Windows to be for ham usage, they would have incorporated our protocols into their kernel.
73 de Brian Rogers - N1URO email: n1uro@n1uro.ampr.org Web: http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2: http://nos.n1uro.ampr.org Linux Amateur Radio Services axMail-Fax & URONode AmprNet coordinator for: Connecticut, Delaware, Maine, Maryland, Massachusetts, New Hampshire, Pennsylvania, Rhode Island, and Vermont.
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
I am seeing the same from Brasil. And it is targeting the whole 44.182 subnet, target port telnet. Since have no open telnet port for non-ampr addresses, it seems no problem.
Marius, YO2LOJ
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Maiko Langelaar Sent: Thursday, January 08, 2015 17:37 To: AMPRNet working group Subject: [44net] lots of telnet attacks from china, australia
(Please trim inclusions from previous messages) _______________________________________________
Is it just my system ?
I'm seeing many many login attempts as root on telnet.
Are they targetting just 44 ?
Maiko / VE4KLM
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
2015-01-08 16:37 GMT+01:00 Maiko Langelaar maiko@pcs.mb.ca:
Is it just my system ?
I'm seeing many many login attempts as root on telnet.
Are they targetting just 44 ?
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.
I'm seeing tons of ip-ip packets directed to my 44.135.124.0/24 subnet, which unfortunately is my RF port, so I've been forced to 'drop' that route so that not to overwhelm our local frequency.
From CN ??? Like someone is scanning the 44 nets ???
Tue Jun 23 19:42:49 2015 - vhf sent: KISS: Port 0 Data AX25: VE4KLM-1->QST UI pid=ARP ARP: len 30 hwtype AX.25 prot IP op REQUEST sender IPaddr 44.135.124.1 hwaddr VE4KLM-1 target IPaddr 44.135.124.25 hwaddr
19:49:32.324324 IP amprgw.sysnet.ucsd.edu > node201.1.168.192.in-addr.arpa: IP 80.3.46.59.broad.sy.ln.dynamic.163data.com.cn.http > 44.135.124.9.45871: Flags [S.], seq 2685507706, ack 4207607809, win 16384, options [mss 1460], length 0 (ipip-proto-4)
19:49:32.324401 IP node201.1.168.192.in-addr.arpa > w143.pcs.mb.ca: IP 80.3.46.59.broad.sy.ln.dynamic.163data.com.cn.http > 44.135.124.9.45871: Flags [S.], seq 2685507706, ack 4207607809, win 16384, options [mss 1460], length 0 (ipip-proto-4) And lots more of them ...
Maiko / VE4KLM
On Tue, Jun 23, 2015 at 5:51 PM, Maiko Langelaar maiko@pcs.mb.ca wrote:
19:49:32.324324 IP amprgw.sysnet.ucsd.edu > node201.1.168.192.in-addr.arpa: IP 80.3.46.59.broad.sy.ln.dynamic.163data.com.cn.http > 44.135.124.9.45871: Flags [S.], seq 2685507706, ack 4207607809, win 16384, options [mss 1460], length 0 (ipip-proto-4)
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
That is very strange as 44.135.124.9 is not in the dns so ucsd should block that.
It is not expected that is routed to Maiko's gateway.
Bob VE3TOK
On 15-06-23 08:59 PM, Tom Hayward wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Tue, Jun 23, 2015 at 5:51 PM, Maiko Langelaar maiko@pcs.mb.ca wrote:
19:49:32.324324 IP amprgw.sysnet.ucsd.edu > node201.1.168.192.in-addr.arpa: IP 80.3.46.59.broad.sy.ln.dynamic.163data.com.cn.http > 44.135.124.9.45871: Flags [S.], seq 2685507706, ack 4207607809, win 16384, options [mss 1460], length 0 (ipip-proto-4)
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 _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On 6/23/15 10:01 PM, Boudewijn (Bob) Tenty wrote:
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.
That is very strange as 44.135.124.9 is not in the dns so ucsd should block that.
maybe a spoof? there's nothing stopping some one from grabbing an encap file and then sending random data to the IPIP endpoints.
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
On 6/23/15 8:51 PM, Maiko Langelaar wrote:
I'm seeing tons of ip-ip packets directed to my 44.135.124.0/24 subnet, which unfortunately is my RF port, so I've been forced to 'drop' that route so that not to overwhelm our local frequency.
It is the internet. It happens, and you can setup a firewall to prevent it if you want.
73's
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.
actually making SIP work really well over amprnet would be cool.
-- 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
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 eric.fort@gmail.com 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 esarfl@gmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Tue, Apr 22, 2014 at 2:26 PM, Don Fanning don@00100100.net 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@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
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@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 don@00100100.net 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 eric.fort@gmail.com 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 esarfl@gmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________
On Tue, Apr 22, 2014 at 2:26 PM, Don Fanning don@00100100.net 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@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
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 drmessano@gmail.com 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@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 don@00100100.net 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 eric.fort@gmail.com 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 esarfl@gmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________
On Tue, Apr 22, 2014 at 2:26 PM, Don Fanning don@00100100.net 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@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@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 k7ve@k7ve.org 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 drmessano@gmail.com 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@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 don@00100100.net 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 eric.fort@gmail.com 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 esarfl@gmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________
On Tue, Apr 22, 2014 at 2:26 PM, Don Fanning don@00100100.net 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@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On Wed, 23 Apr 2014, Danny Messano wrote:
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.
And therein lies the problem. The rest of the SIP world doesn't make that kind of assumption any more so than assuming reaching (123)456-7890 is done by making a SIP call to a de facto destination of 1234567890@1234567890.ampr.org. Seriously?
Unless you want to spend unnecessary time coding this kind of assumption into various SIP software, yeah you do need SRV.
Antonio Querubin e-mail: tony@lavanauts.org xmpp: antonioquerubin@gmail.com
On Apr 23, 2014, at 5:58 AM, Antonio Querubin tony@lavanauts.org wrote:
(Please trim inclusions from previous messages) _______________________________________________
On Wed, 23 Apr 2014, Danny Messano wrote:
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.
And therein lies the problem. The rest of the SIP world doesn't make that kind of assumption any more so than assuming reaching (123)456-7890 is done by making a SIP call to a de facto destination of 1234567890@1234567890.ampr.org. Seriously?
Unless you want to spend unnecessary time coding this kind of assumption into various SIP software, yeah you do need SRV.
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@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
Antonio Querubin e-mail: tony@lavanauts.org xmpp: antonioquerubin@gmail.com _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On Wed, 23 Apr 2014, Danny Messano wrote:
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.
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 e-mail: tony@lavanauts.org xmpp: antonioquerubin@gmail.com
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@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 ...
On Wed, 23 Apr 2014, Marius Petrescu wrote:
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.
No that's not correct. user@host is really just an identity. He/she/it may be reachable by email/sip/xmpp but how it's reached for those different communication modes can flex.
Antonio Querubin e-mail: tony@lavanauts.org xmpp: antonioquerubin@gmail.com
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.
Implementation of services and usage is pretty relevant, as long as it results in doing something fun.
I too have raised the question "couldn't we just use 10/8?". The answer has been made pretty clear the last few weeks and I am onboard. The answer is, really "44/8 can or can not be routed globally and it's up to you what you do with it, how you route it, and if you route it at all". Some discussion of "if I put this online, how will that talk to your same thing" is far from a wasted discussion IMHO.
But hey, if we're back on the "tell me something DIFFERENT you're doing on 44/8 or shut up" or how we "shouldnt be doing anything unless its _something vague and non-specific_ and stop asking me what that might be" then I am happy to QSY.
Sent from my iPhone
On Apr 23, 2014, at 10:03 AM, Phil Frost indigo@bitglue.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ 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. _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
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 Apr 23, 2014, at 8:42 AM, Antonio Querubin tony@lavanauts.org wrote:
(Please trim inclusions from previous messages) _______________________________________________
On Wed, 23 Apr 2014, Danny Messano wrote:
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.
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.
I think there's some wires crossed up here.
You brought up the notion of dialing somehorriblestringofnumbers@ampr.org to reach a user, which is entirely where ENUM comes in. We don't need any of that, for the aforementioned reasons.
Now back to the real need for DNS SRV records. Yes, I addressed much earlier that in SOME instances there may be a need to locate my SIP resource somewhere other than my call.ampr.org hostname. But that isn't the same as "we need DNS SRV to find each other or else", and won't be the case 99.99% of the time.
Now as far as the redundancy and failover aspects... We took a pretty big jump here from "I want to set up Asterisk and call my ham buddies over 44net" to "You need DNS SRV if you're setting up redundant SBCs". What is the goal here? Is everyone going to set up multiple SBCs and we're going to built out a 44net AT&T (I dont see anyone doing the work) or do we need a simple schema in place for all of us to happily dial peer-to-peer SIP and really play with this stuff?
Sometimes I feel like these discussions are networking pissing contests and nothing to do with actually implementing something NOW. If that's the case, RFC 3261 explains everything i've discussed.
Many of us have been doing SIP URI dialing using softphone and hardware endpoints for years with just a little dialplan work in Asterisk or an appropriate softphone. We could start that today on 44net or continue to engineer this ad nauseum.
Danny Messano
Antonio Querubin e-mail: tony@lavanauts.org xmpp: antonioquerubin@gmail.com _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On Wed, 23 Apr 2014, Danny Messano wrote:
Many of us have been doing SIP URI dialing using softphone and hardware endpoints for years with just a little dialplan work in
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@lavanauts.org xmpp: antonioquerubin@gmail.com
The idea would be to have a unified locator of some sort that isn't SIP that could be numeric if you're talking VoIP over 44net. Plus I personally think callsign@callsign.ampr.org should simply be sip://callsign@ampr.org. Could require a global registration/location server but that's just DB work.
On Tue, Apr 22, 2014 at 9:49 PM, Danny Messano drmessano@gmail.com 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@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 don@00100100.net 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 eric.fort@gmail.com 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 esarfl@gmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________
On Tue, Apr 22, 2014 at 2:26 PM, Don Fanning don@00100100.net
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@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Hi All, I'm not buying into the security side of things however
* The program generated my existing APRS code OK * But I had to hit the browser zoom key 10 times to get the font to readable size
I came in from the non 44 side and was required to enter the access code provided from the mail list.
So the program seems to work,
Regards Tony VK3API
On 18/04/2014 1:35 AM, lleachii@aol.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ All,
I've added a new tool that I'd like you to test. This web application should provide the registration code required by APRS software suites. In order to use it, you must browse to:
Works fine from amprnet.
Bob
On 14-04-17 11:35 AM, lleachii@aol.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ All,
I've added a new tool that I'd like you to test. This web application should provide the registration code required by APRS software suites. In order to use it, you must browse to:
http://kb3vwg-010.ampr.org/tools/aprscode or http://44.60.44.10/tools/aprscode
If you're on AMPRNet, you should be able to enter the callsign and look up the registration code. If you access it from outside of AMPRNet, you will be prompted for an access code (1234).
Please let me know how it works
73,
KB3VWG _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
-
amprnet＠wizards.sytes.net -
Andy Brittain -
Antonio Querubin -
Bill Vodall -
Bob Tenty -
Boudewijn (Bob) Tenty
-
Brian -
Brian Kantor -
Bryan Fields -
Charles Hargrove -
Chris -
Cory (NQ1E) -
Danny Messano -
David Ranch -
David Warner -
Don Fanning -
Don Moore -
Enrico Ardizzoni -
Eric Fort -
Geoff Joy -KE6QH- -
Gustavo Ponza -
Heikki Hannikainen -
Jerome Schatten -
Jerry Kutche -
K7VE - John -
lleachii＠aol.com -
Maiko Langelaar -
Marius Petrescu -
Neil Johnson -
Paul Lewis -
Phil Frost -
Phillip Frost
-
Robbie De Lise -
Ronen Pinchuk -
Ryan Elliott Turner -
SP2L -
Tom Hayward -
Tony VK7AX -
William Lewis