44net

44net@mailman.ampr.org

3196 discussions

Re: [44net] dynamic addresses
by Rob Janssen 17 Jan '16

17 Jan '16

> Subject: > Re: [44net] Verifying the identities of IP coordinators > From: > K7VE - John <k7ve(a)k7ve.org> > Date: > 01/15/2016 10:05 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > I beg to differ. I agree with the NAT position, but there are definitely > cases for the use of dynamically allocated addresses. > > Here is one: D-STAR data protocol encapsulates Ethernet frames inside of > D-STAR frames, in turn those can contain IP frames. If I am in a mobile, > driving down a highway and using a series of access points, then receiving > a new 44.x.x.x address via DHCP from those access points keeps me connected > for services I am using. I would implement that using a dynamic routing of a fixed address rather than assignment of a dynamic address (and having to cope with a changing address). Rob

3 3

Re: [44net] RIP Question
by Steve L 16 Jan '16

16 Jan '16

Yes the RIP broadcasts come over protocol 4 from amprgw.sysnet.ucsd.edu Here is a network dump of some directed to my gateway: Network dump of Incoming RIP ############################# tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 04:00:00.218059 IP amprgw.sysnet.ucsd.edu.route > cpe-174-103-224-97.new.res.rr.com.57644: RIPv2, Response, length: 504 04:00:00.218108 IP cpe-174-103-224-97.new.res.rr.com > amprgw.sysnet.ucsd.edu: ICMP cpe-174-103-224-97.new.res.rr.com udp port 57644 unreachable, length 540 04:00:00.218121 IP amprgw.sysnet.ucsd.edu > cpe-174-103-224-97.new.res.rr.com: IP gw.ampr.org.route > rip2-routers.mcast.net.route: RIPv2, Response, length: 504 (ipip-proto-4) 04:00:00.218130 IP amprgw.sysnet.ucsd.edu.route > cpe-174-103-224-97.new.res.rr.com.57644: RIPv2, Response, length: 504 04:00:00.218141 IP cpe-174-103-224-97.new.res.rr.com > amprgw.sysnet.ucsd.edu: ICMP cpe-174-103-224-97.new.res.rr.com udp port 57644 unreachable, length 540 04:00:00.218262 IP amprgw.sysnet.ucsd.edu > cpe-174-103-224-97.new.res.rr.com: IP gw.ampr.org.route > rip2-routers.mcast.net.route: RIPv2, Response, length: 504 (ipip-proto-4) 04:00:00.218550 IP amprgw.sysnet.ucsd.edu.route > cpe-174-103-224-97.new.res.rr.com.57644: RIPv2, Response, length: 504 04:00:00.218573 IP cpe-174-103-224-97.new.res.rr.com > amprgw.sysnet.ucsd.edu: ICMP cpe-174-103-224-97.new.res.rr.com udp port 57644 unreachable, length 540 04:00:00.218582 IP amprgw.sysnet.ucsd.edu > cpe-174-103-224-97.new.res.rr.com: IP gw.ampr.org.route > rip2-routers.mcast.net.route: RIPv2, Response, length: >Hi there >Did I understand correct that the RIP system we use is RIP over the Tunneling ? >Or in other words we need at first to have Tunnel to AMPR Router > >and only then the RIP data can pass through ? > >Any Info Welcome >Thanks Forward >Ronen - 4Z4ZQ >http://www.ronen.org

1 0

Re: [44net] Verifying the identities of IP coordinators
by Rob Janssen 16 Jan '16

16 Jan '16

> Subject: > Re: [44net] Verifying the identities of IP coordinators > From: > Bill Vodall <wa7nwp(a)gmail.com> > Date: > 01/14/2016 10:19 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > >> >When someone applies for an address... > Transient users don't need static or even real IP addresses. We could > re-invent DHCP... I am firmly against that. Contrary to the Internet as it is now, we are not a collection of transient users that only use a couple of centralized services, but we are all peers that should be able to both use and offer services and make connections in all directions. That is what makes us different from ordinary internet users, and using dynamic or even translated addresses kills all that and makes the whole AMPRnet superfluous. Rob

6 7

Need a New Thread titles.. WAS:RE: Verifying the identities of IP coordinators
by Jerry Kutche 15 Jan '16

15 Jan '16

Can we start a new thread title for all the items that are coming up... I marked this thread on my system as DOA and I see I am confused going by the thread titles... No Offense.. Just asking for some semblance of order.. Many Thanks 73 Jerry N9LYA -----Original Message----- From: 44Net [mailto:44net-bounces+n9lya=nwcable.net@hamradio.ucsd.edu] On Behalf Of Marius Petrescu Sent: Friday, January 15, 2016 5:41 PM To: AMPRNet working group <44net(a)hamradio.ucsd.edu> Subject: Re: [44net] Verifying the identities of IP coordinators (Please trim inclusions from previous messages) _______________________________________________ Now really... You actually want a dynamic DNS? We can not manage the regular DNS entries in the portal yet. But what is stopping you to send a DNS robot update mail on IP change? Marius, YO2LOJ _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

1 0

Re: [44net] Verifying the identities of IP coordinators
by Steve L 15 Jan '16

15 Jan '16

While using LOTW certificates is quite ingenious, I think the whole process to extract the keys will be a big hangup for the less technical folks. It really needs to be as easy as possible, like how you can use you facebook login (oauth token) to log into other sites. Basically it your ARRL login should work like that, so you can login to the ampr portal, qrz, etc.

24 38

Re: [44net] Verifying the identities of IP coordinators
by Rob Janssen 14 Jan '16

14 Jan '16

> Subject: > Re: [44net] Verifying the identities of IP coordinators > From: > "Marius Petrescu" <marius(a)yo2loj.ro> > Date: > 01/14/2016 08:10 AM > > To: > "AMPRNet working group" <44net(a)hamradio.ucsd.edu> > > > The reason is simple why not to allow automatic requests: > The coordinators may have a certain IP allocation scheme in there minds. Maybe regional, maybe some other criteria. > That means that not every request out of the blue fits that scheme. > So an IP range may be unallocated, but it does not fit the allocation scheme. > An coordinator would change the requested one allocate the right one, which would not happen in an automated system. > > e.g. in YO, I allocate IP ranges based on regions, so that the first number in the block fits the requestors region number (the same as in the callsign). > I had requests like "please allocate 44.182.35.xx to me", the user being in region 8. > It resulted in allocating the first unused 44.182.8x.xx /24 subnet to him, and not the original requested one. > This would not have been possible in an automated system. > > Marius, YO2LOJ It is the same here, Marius. When someone applies for an address I need to know where they are located, if applicable to which access point they want to link, if they want a single address or a subnet, what size of subnet they need, a motivation when that is larger than the default /28, etc. Once I have that information I look at the already assigned addresses, and assign them one that fits. (there is a different area in each subnet where single addresses and subnets are allocated) Sure it could all be catered for in input forms, but the amprnet portal currently doesn't, and upgrades to its functionality appear to occur only very infrequently. I don't think it is worthwile to spec out everything and have someone spend time on implementing it, only to find ourselves locked into that system which may not be optimal once some decision is made to handle things differently. Furthermore, many applicants really need some guidance and make requests that are incomplete or not justified (e.g. request allocation of a /22 network for a single station). The semi-automatic mechanism appears to work well and makes it easy to ask for more information. Rob

3 2

Portal volunteers [was: Verifying the identities of IP coordinators]
by Tom Hayward 14 Jan '16

14 Jan '16

On Wed, Jan 13, 2016 at 6:25 AM, Brian Kantor <Brian(a)ucsd.edu> wrote: > The existing portal works fairly > well for a first cut at making one. Undoubtedly we'll refine it but that > depends on volunteers to do the design and programming (PHP, Javascript), > and so far several calls for volunteers have fallen on deaf ears. This isn't completely true. You can grep the archives for "I'll be happy to help with the programming" to find at least one offer. Alternatively, my opinion is that Chris would get more help if the project were open sourced. Now instead of recruiting volunteers, he will have contributors. This allows for a lot more flexibility. For example, a ham in one part of the world is stuck at home on a rainy weekend is setting up an AMPR system and encounters a bug. Meanwhile, Chris is enjoying a weekend away from the computer in a part of the world with more favorable weather. With an open source project, the first ham can dig around for the bug and send Chris a patch without any pre-approval. When Chris returns, he can vet the patch before applying it to the SVN [or whatever technology] repo. This significantly lowers the bar for volunteers and administration. If the portal is open sourced, expect a patch from me within the first week. Tom KD7LXL

4 3

Re: [44net] Verifying the identities of IP coordinators
by Steve L 13 Jan '16

13 Jan '16

Re-validating on a regular/annual basis should be for everyone not just coordinators and gateway ops. It keeps contact information current and could also confirm if they wish to keep their netblock allocation. Think of it as a subtle reminder to maybe get back on board with something they may have put off. : And allows address space to be returned to the pool, and any associated DNS entries in that address space to be removed as well as any associated gateways. I think I might have been the first to ask of the portal project was going to be open source. My thoughts at the time was it seemed like a number of regional BGP connected chucks where breaking off and I figured they may also want to implement a user end kind of portal. If there are some security by obscurity concerns in its design, then we just need a github type of thing hosted on 44net so that non hams are restricted from viewing and submitting to the project. And even if that doesn't happen for the portal, I think a ham only github type of thing might be a good idea. A number of ham projects get picked up and spun by commercial folks. The earliest example is probably Phil Karn's NOS code. And now a present day example would be about non licensed folks getting access to modified atheros drivers or the CS7000 firmware, etc.

3 2

Re: [44net] 44Net Digest, Vol 5, Issue 12
by f5pbg＠free.fr 12 Jan '16

12 Jan '16

Le 12/01/2016 20:00, 44net-request(a)hamradio.ucsd.edu a écrit : > The original suggestion was that there was a way to bypass simple > address assignment by automating the process. No possible i think, because we must verify the real identity of the persons requesting IPand if this verification is automatic it will be very easy to pirat the system... For example if I have a doubt about the person, I phone him to check the identity. An automatic system can do this. ;o) Best regards, Ludovic - F5PBG.

1 0

Re: [44net] Verifying the identities of IP coordinators
by ve1drg 12 Jan '16

12 Jan '16

Third ed it.. --Ted Gervais 1464 luxury aveWindsor OntarioN8p0a9 -------- Original message -------- From: ve1jot <ve1jot(a)eastlink.ca> Date: 2016-01-12 12:00 AM (GMT-05:00) To: AMPRNet working group <44net(a)hamradio.ucsd.edu> Subject: Re: [44net] Verifying the identities of IP coordinators (Please trim inclusions from previous messages) _______________________________________________ seconded! On 16-01-10 01:40 PM, Paul Lewis wrote: > (Please trim inclusions from previous messages) > _______________________________________________ > Thank you Brian for those kind words > and also for the work you do and your team in the background support > for the past 25+ years > paul g4apl > In message <20160110145927.GA32116(a)UCSD.Edu>, Brian Kantor > <Brian(a)UCSD.Edu> writes >> (Please trim inclusions from previous messages) >> _______________________________________________ >> There seems to be some confusion here. The discussion was never about >> verifying the identities of coordinators. >> >> The original suggestion was that there was a way to bypass simple >> address assignment by automating the process. >> >> I explained at the time that the coordinators perform a valuable service >> that can't be automated in any practical way. >> >> In fact, many coordinators do far more than assign addresses - they >> consult with users and provide assistance in getting their stations on >> the net. Many of the people currently using AMPRNet would not have been >> able to do so without the help of their local coordinator. >> >> I think the coordinators, many of whom have been performing that service >> for years, deserve a round of thanks from the community. They certainly >> have my appreciation for their hard work and dedication. >> - Brian >> >> _________________________________________ >> 44Net mailing list >> 44Net(a)hamradio.ucsd.edu >> http://hamradio.ucsd.edu/mailman/listinfo/44net > _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net