44net

44net@mailman.ampr.org

3194 discussions

Re: [44net] gateway file
by lleachii＠aol.com 10 Feb '13

10 Feb '13

Steve, I am running EchoLink Proxies at 44.60.44.253:443 and 44:60.44.254:80 I am woking on a SIP based VoIP system, it is not up at this time. ~Lynwood KB3VWG

3 4

BGP feed
by C.J. Adams-Collier KF7BMP 10 Feb '13

10 Feb '13

Hey folks, I'm going to stand up a quagga server over at 44net-tunnel-endpoint.org in the next week or so. Would any of you be willing to give me a private feed of the v4 table (and v6 if you've got it) using a reserved AS number on my end? It's been a while since I've done this, so be gentle with me ;-) From http://tools.ietf.org/html/rfc1930: 10. Reserved AS Numbers The Internet Assigned Numbers Authority (IANA) has reserved the following block of AS numbers for private use (not to be advertised on the global Internet): 64512 through 65535 Thanks much! C.J.

1 0

Re: [44net] 44Net Digest, Vol 2, Issue 23
by Rob Janssen 07 Feb '13

07 Feb '13

44net-request(a)hamradio.ucsd.edu wrote: > Last time I tried doing > whois on a name it failed. The spammers have made it impossible to put up a > whois because they mined them all for valid emails so organizations had to > abandon it. Maybe it varies between TLDs. I never got much spam that I could trace to .nl domain name registration (note that .nl now no longer reveals contact info via whois, but they used to in the past). On the other hand, what really buried me in spam is registering for some port numbers and a organization unique ID at IANA. They published the requester's mail in a text file on their site, and for port numbers it is in /etc/services. I have had to abandon some mail addresses because of it. Rob

1 0

Re: [44net] 44Net Digest, Vol 2, Issue 23
by Rob Janssen 07 Feb '13

07 Feb '13

44net-request(a)hamradio.ucsd.eduwrote: > Rob, > > I have a dutch licence and there is nothing in there about host names. > > Is this only a requirement for unattended gateways as these need a > separate licence > from the government there? > > Bob (Boudewijn) VE3TOK I reply to this item only to avoid posting several messages, but I have read the other replies as well. Back in the days when we were still doing a packet network, the situation was like this: The license said "each packet should be identified by the callsigns of the station where the traffic originates from, and the station that is actually transmitting the packet". This made point-to-point packet legal, as well as digipeated packet. Both comply to that requirement. The method used by NET/ROM was illegal. It transmitted packets from the nodes using a modified originator callsign. The packets had the callsign of the original source, but not the callsign of the node that was transmitting them. When I adapted NET/ROM into NET, I created a system where the exit node transmitted a "faked" digipeated packet that looked like if the node had actually digipeated a packet (while it in fact was making a downlink connection). That made it formally compliant to the license requirements, and was also more convenient for the users as it showed where the traffic was actually coming from. The same thing was done in Germany, in other software. Then look at IP. An IP packet transmitted via the network and sent by a node/router has the AX.25 callsign of the node transmitting it, but does not carry the callsign of the original source. Someone consulted the authorities about it. He got the assertion that it would be accepted as identification if there would be a publicly available mapping between IP address and callsign, so they could consult that when wanting to determine the source of the traffic. All the time after that, the hosts file for the Netherlands has been publicly available both on the BBS system and on telephone BBS (in those days) and Internet (later). And there was the Internet DNS with this information. It may be that the current license no longer explicitly states the callsign requirements, there have been changes. I just have continued to always use the callsign as part of all hostnames assigned to allocated IP addresses within 44.137... (callsign.ampr.org or label.callsign.ampr.org) Note that all this is only the situation in the Netherlands, I have no idea how regulations are in the US or elsewhere. Also note that all this is mostly academic, as packet radio is now formally illegal in the Netherlands except for stations with a "notice of variation" for unattended operation. Why that, you ask? Well, it went like this. There has always been a NOV requirement for unattended stations. Nodes, repeaters, BBSes etc required such a notice from the authorities to allow operation without the operator being present. User's packet stations did not require this NOV as long as the operator was present during use of the station. And many operated on the edges of what was really allowed, it wasn't really enforcible anyway. (e.g. the station transmitting a file while you are watching TV or sleeping, is that "attended"?) Of course an unattended phone repeater also requires a NOV. To get one, one needs to fulfill certain criteria like a minimal distance to another repeater on the same band. And there is co-ordination to distribute the limited number of channels. There are always some people do not want to play within those rules and started operating "attended repeaters" on all kinds of imaginable channels, and D-STAR hotspots, sometimes after a request for an NOV was denied to them. It somehow irritated the authorities and they redefined the "attended" requirement: it must be the operator himself, either directly or via some authenticated link guaranteeing it to be only him, who keys the transmitter. A repeater or hotspot, where the transmitter is keyed by the reception of a signal not from the operator, is now declared to be in requirement of an NOV no matter if the operator is actually present or not. And it is also stated that there will be increased effort to monitor and effectuate this regulation. Unfortunately, a packet station, even with the operator sitting at the keyboard, is now outside these bounds. The transmitter is keyed as a result of someone transmitting towards you, if only to transmit an acknowledgement. And this is explicitly no longer allowed in the definition. I have no idea if this has been the intention and what they now actually think about packet. It is very likely that we are only the victim of the desire to regulate the phone repeater mess, and it was not the intention to disallow point-to-point packet or user-to-node packet as well. Rob

1 0

Re IPv6 for www.ampr.org
by Daniel Curry 07 Feb '13

07 Feb '13

I am glad to see that IPv6 being available Looking forward on the progress. K6DLC -- Daniel Curry PGP: AD5A 96DC 7556 A020 B8E7 0E4D 5D5E 9BA5 C83E 8C92 IPv6 Sage Certified San Francisco/Silicon Valley AmprNet Co-coordinator [44.4.0.0/16]

5 6

Windows Based AMPR Router
by lleachii＠aol.com 07 Feb '13

07 Feb '13

All, Has anyone attempted to setup an AMPR gateway using Microsoft Windows (http://technet.microsoft.com/en-us/library/cc940485.aspx)? I surmise that the tunnel setup is straightforward; and ActiveState ActivePerl (http://www.activestate.com/activeperl) can be used to run RIP44d, I have not reviewed the RIP44d file as of yet; but I assume editing the line that adds routes to the Routing Table would be all that is needed. The Perl Packages 'interface' and 'IO-Socket-Multicast' are available through ActivePerl for Windows, has anyone tried a Microsoft setup before; did you have success/failure? I wanted to make sure no one has already tried the Windows OS before I explore; and if they have, can they provide some insight and instructions. 73, Lynwood KB3VWG

1 0

Re: [44net] 44Net Digest, Vol 2, Issue 22
by Rob Janssen 07 Feb '13

07 Feb '13

44net-request(a)hamradio.ucsd.edu wrote: > the DNS functionality is a separate module and is not tied to the name of the IP/subnet, not everyone uses their callsign as the DNS name But that is a license requirement! We need a mapping between IP address and callsign for legal use of IP on amateur radio.... (ID requirement) Rob

16 21

IPv6 for www.ampr.org
by Brian Kantor 07 Feb '13

07 Feb '13

Tony, AH6BW, has set up an IPv6 proxy to enable IPv6ers to reach www.ampr.org. This should have no effect on ordinary IPv4 access to the site, but if you have any trouble reaching it, please let me know. FYI, the entry in the nameserver to implement this is www IN AAAA 2605:b00:0:2:211:2fff:fef6:4287 which is how the address for an IPv6 host is entered in the the 'bind' nameserver. - Brian

7 9

Re: [44net] 44Net Digest, Vol 2, Issue 21
by Rob Janssen 06 Feb '13

06 Feb '13

44net-request(a)hamradio.ucsd.edu wrote: >> >But it has the disadvantage that you spread the rarely occurring task over many >> >people who do it only once and do not have the knowledge and skills to perform >> >it well. I'm afraid this will lead to many wrong subnet specifications (already seen), >> >strange names in the DNS, questions, etc. > That's just a learning curve which is easily fixed. I think it is better to have the learning curve once and not for every user. It is already very unclear to me (as an expert in IP addressing and a long-time co-ordinator) what the system will exactly do when I perform certain actions, and I think it will be nothing short of a mystery to those that just want an address and have no idea how IP addresses are structured, what subnets are, and how DNS fits in. > >> >I prefer to handle the task for the entire country and have the system only >> >administer what has been assigned, not delegate the subassignments. It is >> >a small country and I get only a couple of requests per year these days. > The system is flexible, if that is how you want to administer the subnet you are responsible for, then go ahead, all your allocations will therefore be to end users instead of regional co-ordinators and it will be your responsibility to keep the portal up to date and if there are any problems, you will be the point of contact to respond and fix the problem. It's more work for you, but if that is how you prefer to manage your subnet I don't see a problem. > > I guess what we need is a facility for co-ordinators to enter allocations to end users manually, I can sort that out. > > Regards, > Chris > I don't mind if users can submit requests for subnets via the system, as long as that does not automatically mean that they become the co-ordinator for that subnet. They get the adressing space, submit the requests for names within that space, and I validate them. That is how it has always worked, and it has served well to prevent silly stuff like non-callsign entries directly under ampr.org from appearing within the 44.137 subnet. For single adresses, it would be preferable if there is a single request form that supplies both the name and desired subnet, and leaves the assignment of the address to the co-ordinator, who approves the entire request in a single action. But if that is too much programming work and it is more convenient to leave the separation between address assignment and DNS mapping, that is not a real problem because of the current rate of requests. Rob

4 5

amprnet dns zones
by Eric Fort 06 Feb '13

06 Feb '13

I'm seeing a lot of good things in the works in the reforming of amprNET/net44 including how ip address assignments and allocations are to be handled and managed, routing info exchanged dynamically via rip and other protocols, and the moving away from a single central point which all traffic has to essentially tunnel to as address space can now once allocated be tied to the appropriate AS and routed via BGP. all great things being done. there are a few things though I have not heard happening that I'll ask if they have been considered and what others thoughts may be. This for the most part deals with a gateway operator being able to manage the DNS zones pertaining to the operation of their gateway and it's users. for the sake of discussion lets say we have a gateway operator with a /24 block assigned to their gateway and let's say that block is 44.128.128.0/24and lets say their call was gw4opr: I would propose that along with the allocation of that block that gateway operator have the option to host and manage the 128.128.44.in-addr.arpa zone on their DNS servers. I would also propose that those who would choose to could host and manage their own DNS zones, in this instance *.gw4opr.ampr.org. It seems to just make sense that reverse dns would be managed by the ones responsible for and closest to the address space assigned and that one ought to be able to manage their own DNS zone without having to go through their address coordinator for every last dns update as long as they are willing to accept delegation of responsibility for their zone. what are the thoughts on this from others on this list? Personally I think delegation of zones is a great idea, but perhaps I missed something. it would seem to further lighten the load on local coordinators. That said, why should we or why should we not plan for, allow, and even encourage, delegation and self management of DNS zones directly by those closest connected to and most responsible for them? AF6EP

3 2

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net