44net

44net@mailman.ampr.org

3198 discussions

Overlapping gateway subnets
by Michael Fox - N6MEF 29 Mar '13

29 Mar '13

I know this is fine in regular IP routing, but is it o.k. with the AMPRgw? I have a gateway that serves a /28 address space. I'd like to do some testing using a couple of the addresses in that space on a different gateway. So, I'd like to add another gateway entry for just those two addresses without modifying the existing gateway entry for the /28. Regular IP longest match should prefer the /32 matches for the new gateway over the longer /28 match for the existing gateway. But before I implement, I wanted to verify whether or not this would be o.k. with the portal database, the amprgw RIP routing mechanism, etc. BTW, this would be a nice, generalized solution for a backup gateway. That is, if the more specific route goes away, the more general route could be used. So, is this o.k. to do or not? If not, why not? Thanks much, Michael N6MEF

4 5

Newbie issue
by Marc, LX1DUC 27 Mar '13

27 Mar '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello and sorry to bother you with this. I have added a gateway (46.29.183.253) via the portal and I have added subnets to it. I can see the encap.txt has been updated and I do receive RIPv2 Multicast Messages from 44.0.0.1. I have setup rip44d and it is populating my routing table. Example: #ip route get 44.0.0.1 44.0.0.1 via 169.228.66.251 dev tunl0 src 44.161.229.126 cache window 840 However when trying to ping 44.0.0.1 from 44.161.229.126 I don't get any replies. I have followed the outgoing ICMP packets, they get encapsulated on my gateway and the outer IP destination address is 169.228.66.251. The packet travels without troubles thru AS51405 (the home network of 46.29.183.253) and I can actually see the packet going out to the transit network (currently AS5577, in case you're interested). So I'm really really sure that the IPIP packet containing the ICMP echo request makes it out into the Internet. I have also ran traces on all of the ingress connections towards AS51405 and I cannot see a single coming back from 169.228.66.251. Is there anything I'm missing? I really appreciate your help. BTW I'm allowing inbound packets carrying protocol 4 and ICMP on the gateway, but as I don't see packets addresses towards my gateway in the upstream network, I'm guessing it's not the firewall on my gateway H-i. vy 73 de Marc, LX1DUC - -- http://lx1duc.mcs.tel -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRUrArAAoJEHFIN1T8ZA8vXkUP/38puOAwTWz38Y9UEinjz+HM kBLQKzeYUkVH/f1xjjVuqaiqzXss37XeAL9XeRIqkJ8znanWac8LznYl42Zvyrph BVaRvp6+M3m4CRnNpy7LuRFfTW+DVNIS88TR+jiD+GYxXFiXc7sQSL98ozPPHYSu QUl2pb4qqXXkVOmwjbcUami4HsBj18oCtcwE+qVwv73EBlW/S0ff6HiYawnuJPzK yznMEeStR58K1+9IfX+o6S406JT8VnBJDQ7W6WHU0aHv3qLA+FM7Mk5DBEtHJRE5 5lwkqFwq71XSmQAX2oGWaC1rTk6pBJoSgjGAEssioP7D1hqJAHuc2fR15zDQkxXW L7z39xc/J2z7sZleqlqldjeY9+7pA+w6opJTaZFjdMdf+yq/zuJPpWv36Pm616xy zPnNorLHwe2WJL79+4ZPzDZamp355ATO7LFF38sx8rHJiXGuP+wb1Udi2fSG9J1O 5jYM4XHKWQnVRdTeit2WkUoEW0c+pgN0nsQ4iReXEragXdmhnpXmQhagKZP10/S5 0TMplR1D/3LLVTMRnjhxyUfY9ZtA6dw1S9DyZQadeJh6Y0KD5QoistEOgXqMnoZS a+c5GN/cc/BSxdHrLnc+yk9FxjL+I2fuU6bwuf27fjcXuTSoGglqZMCMM636Rkj1 scOCTXhoQdfwIeA5aV/z =Yi7/ -----END PGP SIGNATURE-----

2 1

Questions
by Marc, LX1DUC 24 Mar '13

24 Mar '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Good evening dear OMs, I'm really new to this Mailing-List. I have been reading through the information available online but I have a few remaining questions: - - Can there be more than 1 coordinator for one single area (e.g. 2 OMs handling a country conjointly)? - - Do the former tunnels still exist for delegations which haven't been moved/migrated to the new portal? (Or are they offline from the Internet side of things?) - - The new system/portal seems to favor a mesh network of tunnels, are intra-country tunnels (no directly connected to the AMPR gateway but connected via a local gateway (which in turn is connected to the AMPR gateway)) depreciated or unrecommended? - - When I checked a few years ago, very very few networks within 44.0.0.0/8 were announced in the DFZ (like 1 or 2), this seems to have increased. Is it recommended today to announce a delegation or parts of it directly? I'm sorry if these questions have been answered before, I really tried finding them, but I might have searched using the wrong terms/words. vy 73 de Marc, LX1DUC - -- http://lx1duc.mcs.tel -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRTip1AAoJEHFIN1T8ZA8vRPAP/0oCcMWjMfOnlvdYxsp3+wUY WVlwG92jKXVxrdXMKDVA+bqqyW6S5+xfMAA/nry0p+m/BbVOALLskcGeZncVspzu MjZzmC+9ueO1hRRiQ9F6gFN0X+tTHDCHJRdJo83J0W4acw8WgFTQv/hxk9DuvySt zzMJp7K0YKfh6bHsyvML4iePh4+Ra0B+3xyW8Dp0hnoesasRuCDBUSuENyp3NGL3 4fRH0FUYB29B+hbXH6aWZlbYe1DhwkrX7V/azeRmbDdgkTFBnfb/uj/+Sqp/H7d/ 80nznr/su/ylxiGgW+fmBcoosbXcGlCzQ75/wT2Hf54k40zOeCPLI37Chc8CRVGd /XgL/UyodGzg/SyJg0bQ/T63v969y/7xvdvUaXH182JyObNextPN+m5Ur6evMjIq s6KhiGoJoLTfFEv/pEIDPPnITSwyx7dWw8IzAUp+UbscbaRNGbywp/T/GuhYpKhR N3z2JJmrKXULp3rW/SYhSuYiMi72VVy83I/vnkVzK8J7CM09b06oenPLpt6Af8r8 2AEVbTKI0nmjBcg7lR9t+FxQSzMC+N3Jglt0RTjI76Uq5PpOdcBHL6/ISmXkYwk9 2H8yBkDz6suy1g5QPxu2WjCntIcgOZYYGNMAYxHRU69XbQMk/9x1BScGmhSMKIeR U8de5N0G64S6JxdgtovR =AKXa -----END PGP SIGNATURE-----

2 2

encap.txt
by Jann Traschewski 13 Mar '13

13 Mar '13

Hi guys, there are some "suspicious" entries in encap.txt: route addprivate 44.131.192/29 encap 44.131.192.1 route addprivate 44.24.115.17/32 encap 44.24.115.17 There are even some other gateways listed with IP-addresses out of 44/8. 73, Jann DG8NGN -- Jann Traschewski, Lenbachstr. 6, D-90489 Nuernberg, Germany Tel.: +49-911-696971, Mobile: +49-170-1045937, E-Mail: jann(a)gmx.de Ham: DG8NGN / DB0VOX, http://www.qsl.net/dg8ngn

9 13

Re: [44net] Portal registrations
by lleachii＠aol.com 13 Mar '13

13 Mar '13

Bill, WA7NWP, I'm not sure this is best suggestion for many reasons: - There was a discussion a few weeks back where it was determined that all stations do not necessarily run telnet (while having others test connectivity to my station, some were attempting to telnet to me). For example, my station is not a TNOS/JNOS based router, and therefore does not provide Converse (the telnet-based service we're referring to) by default. Under that guideline, my allocation would be purged. - We also determined that, while all stations should make their IP addresses ping-able, that was not necessarily the case (either by intent or error). - For various reasons, AMPRNet allocations may not necessarily be online or available through AMPR - A Station does not necessarily have to download the encap to have a working allocation (one could manually add static routes from the portal list or use RIP44, for example) - It would be impossible to use the download guideline for those using the RIP44 routing protocol, as it is multicast; and doesn't know what stations are receiving it or using it We have to be mindful that all stations may not be identically configured, use the same Operating Systems, routing protocols nor system configurations to accomplish connectivity to AMPRNet. 73, Lynwood KB3VWG On 03/12/2013 03:00 PM, 44net-request(a)hamradio.ucsd.edu wrote: > Automate it for now and the future... If a client doesn't > ping/poke/telnet/download or whatever within 30days/3months/whatever - > purge the entry. You know - just like DHCP but at a higher level.. > :) > > Bill, WA7NWP

5 5

Just a sugestion.. a beginning..
by Jerry 13 Mar '13

13 Mar '13

Just have them login once a year and reup their registration.. Like they make you do for repeater coordination.. Allow a 90 day grace period and then lock it for 30 days if still no contact they obviously have abandon it.. or will return when they realize it is down.. Time frames I suggest are just that. That way no notice, no email reminders, no bother to the system or anyone.. They must login or get booted... Not trying to be mean.. but lets say ham A has died.. The portal may never know this... Lets say they changed email, no email reminder will ever reach them.. Let's say they lost interest, even an email or post card could simply get ignored.. If it's simple and the system can send an email to the Last Known Good email at say 11 Months... Fine.. Or make it a rolling 12 months from last login to the portal.. But no need to make it any more than simple.. Let's keep its K.I.S.S 73 Sorry working late and bored.. lol -----Original Message----- From: 44net-bounces+n9lya=blueriver.net(a)hamradio.ucsd.edu [mailto:44net-bounces+n9lya=blueriver.net@hamradio.ucsd.edu] On Behalf Of lleachii(a)aol.com Sent: Tuesday, March 12, 2013 4:37 PM To: 44net(a)hamradio.ucsd.edu Subject: Re: [44net] Portal registrations (Please trim inclusions from previous messages) _______________________________________________ Bill, WA7NWP, I'm not sure this is best suggestion for many reasons: - There was a discussion a few weeks back where it was determined that all stations do not necessarily run telnet (while having others test connectivity to my station, some were attempting to telnet to me). For example, my station is not a TNOS/JNOS based router, and therefore does not provide Converse (the telnet-based service we're referring to) by default. Under that guideline, my allocation would be purged. - We also determined that, while all stations should make their IP addresses ping-able, that was not necessarily the case (either by intent or error). - For various reasons, AMPRNet allocations may not necessarily be online or available through AMPR - A Station does not necessarily have to download the encap to have a working allocation (one could manually add static routes from the portal list or use RIP44, for example) - It would be impossible to use the download guideline for those using the RIP44 routing protocol, as it is multicast; and doesn't know what stations are receiving it or using it We have to be mindful that all stations may not be identically configured, use the same Operating Systems, routing protocols nor system configurations to accomplish connectivity to AMPRNet. 73, Lynwood KB3VWG On 03/12/2013 03:00 PM, 44net-request(a)hamradio.ucsd.edu wrote: > Automate it for now and the future... If a client doesn't > ping/poke/telnet/download or whatever within 30days/3months/whatever - > purge the entry. You know - just like DHCP but at a higher level.. > :) > > Bill, WA7NWP _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html

3 2

DNS entries
by Michael Fox - N6MEF 12 Mar '13

12 Mar '13

I've lost track of the status of the portal functionality. We have a block of addresses allocated to our county network (44.4.50.0/28). I also have two addresses allocated for my personal machines (44.4.2.152, 44.4.2.153) But when I log into the portal I see no active records. At some point will the existing records appear in the portal when I log in? Thanks N6MEF

10 17

Re: [44net] Portal registrations
by lpernot＠magma.ca 11 Mar '13

11 Mar '13

I don't understand how I can allocate anything out of 44.135.0.0/16 Since I still can allocate host out of Ampr host robot at UCSD. You need a guide for this website ----- Reply message ----- From: "Brian Kantor" <Brian(a)ucsd.edu> To: "AMPRNet working group" <44net(a)hamradio.ucsd.edu> Subject: [44net] Portal registrations Date: Mon, Mar 11, 2013 13:20 (Please trim inclusions from previous messages) _______________________________________________ It's especially important for the area coordinators to get themselves registered as such with the portal. I think that in a few months we'll just have to consider any regions with no registered coordinator as abandoned by their former coordinators. Similarly with gateways: at some time in the future gateways which aren't registered with the portal will have to be dropped from the encap file. People with existing allocations should make sure that their own allocation is registered with the portal, if necessary by going through the portal allocation process. If you do this, be sure to include a note that it's a re-registration of an existing allocation. - Brian _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html

11 16

encamp file emailed on change
by Chris Smith 10 Mar '13

10 Mar '13

Hi All, FYI - There was a bug in the code that emailed out the encap file to anyone that had the "only when changed" option set, resulting in the encap file not being emailed at all to them. The bug has now been identified and fixed, so if anyone wants to receive an emailed copy of the encap file only when anything has changed, please login to the portal and click on: "Gateways" -> "Options" and alter the "Frequency" to "Only when changed". If you do not wish to receive an email copy of the encap file, please ensure that the "Email" field on this same page is blank. Thanks, Chris

2 1

Co-ordinators new functionality on the portal
by Chris Smith 04 Mar '13

04 Mar '13

Following requests from co-ordinators, I have added some additional functionality to the portal. If you are a country or regional co-ordinator you now have an extra menu link "IP Allocations" from where you can view / edit all the subnets you have allocated. 73 Chris - G1FEF

5 6

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net