44net

44net@mailman.ampr.org

3196 discussions

Re: [44net] documentation of gateway move
by Michael Fox 27 May '17

27 May '17

Yes, thanks.M Sent from my Verizon, Samsung Galaxy smartphone -------- Original message --------From: Brian Kantor <Brian(a)UCSD.Edu> Date: 5/26/17 18:31 (GMT-08:00) To: AMPRNet working group <44net(a)hamradio.ucsd.edu> Subject: Re: [44net] documentation of gateway move (Please trim inclusions from previous messages) _______________________________________________ I assume you meant "can't". Updates to the wiki are in progress. I think there ought to be an 'amprgw' page on the wiki, but there isn't one yet. I'll try to get to writing one soon. - Brian old address: 169.228.66.251 old hostname: amprgw.sysnet.ucsd.edu New address: 169.228.34.84 New hostname: AMPRGW.UCSD.EDU Cutover date: TBD On Fri, May 26, 2017 at 06:20:34PM -0700, Michael Fox - N6MEF wrote: > I can find where the new amprgw info is documented. > Shouldn't the old/new hostname, external IP address and cut-over date appear > prominently somewhere? > Michael > N6MEF _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

1 0

Re: [44net] Good News! and some changes coming
by Rob Janssen 27 May '17

27 May '17

> I've already tested the 44.0.0.1 address using loopback and it > works ok, and I've tested inbound using 44.128.0.1, and it > works ok too. I think things will be ok. > I don't like to bother the campus networking people more than I have to. Ah, I thought that 44.0.0.1 was running on the same machine as amprgw and would be moved as well... so that ciould be done before. Apparently it is a different box. Rob

2 1

Re: [44net] Good News! and some changes coming
by Rob Janssen 27 May '17

27 May '17

> Don't most hosts and routers ignore ICMP Redirects > out of security concerns these days? Certainly for such external addresses. Locally on the LAN it usually works. (e.g. when you have two routers and one sends redirects to the address of the other, both in the local subnet) Rob

1 0

Re: [44net] ampr-ripd 2.0 released Marius Petrescu marius at yo2loj.ro
by Rob Janssen 26 May '17

26 May '17

> - brought back option -r, to allow using multicast sockets by default > and raw sockets as a backup for systems with multicast issues. This will > hopefully sort out the firewall filtering inability on previous releases > since 1.13. I had to put back the -r option that I had cleaned up from my start script as it still does not work with the multicast socked on Debian Linux with kernel 3.16. I remember it failed after some kernel update and it apparenty is still broken. However, I do not mind using the -r option, only want to remind people that they may need to put it back. Rob

4 22

Re: [44net] Good News! and some changes coming
by Rob Janssen 26 May '17

26 May '17

We do not send outgoing traffic via amprgw so no change is necessary, but I updated the address on our info page (that says "use our address instead of 169.228.66.251 as your default gw"). It would probably be a good idea to change the route for 44.0.0.1 before the incoming routes are switched over, so it can be tested from the inside. Rob

2 1

Warning - Bad Startampr/Linux Scripts on Internet
by lleachii＠aol.com 26 May '17

26 May '17

All, It's my understanding that there are multiple copies of the original Startampr script on the Internet. What I have not noticed until alerted by two operators that attempted to implement those copies in their devices, are the following: - Scripts NOT distributed from my site at http://44.60.44.10 ON AMPRNET include the misuse of the -a argument to run the RIP44 daemon(s). - The syntax used on the Internet scripts ('use -a argument to remove your allocation from the table' by a. specifying WAN IP IN rip44d; vs b. specifying 44 allocation CIDR IP as in ampr-ripd, are reversed. - This appears to be a documentation bug made by a copier who used my original scripts (made for rip44d) and converted them to work for ampr-ripd. - if you use my scripts placing lookups for your local 44 LAN in the main table, this issue wouldn't affect you 73, -Lynwood KB3VWG

1 1

Re: [44net] ampr-ripd 2.0 released Marius Petrescu marius at yo2loj.ro
by Rob Janssen 26 May '17

26 May '17

> >/Everyone is free to use the -g option if needed /> Yes, but is eth0.2 a valid entry? The parameter of -g is an IP address. It it not the IP address of an interface but of the gateway to the internet. So specifying an interface like eth0.2 does not make sense. You could use something like this: .... -g `ip route list | grep '^default' | sed -e 's/.*via //' -e 's/ .*//'` Rob

2 1

Re: [44net] non-operational gateways
by Rob Janssen 26 May '17

26 May '17

> Thinking about this, I recall that I run an IPv6 tunnel with Hurricane > Electric in the same manner. They require that I allow ICMP - Echo > Request to the border. The tunnel doesn't come online at their end, > until they receive an Echo Reply from the IP I specified (either > statically or with DDNS). > Just a rule used by one ISP. I think it is not required to allow pings to the outside address, and it may be difficult for some people to fulfill that requirement (as it may be part of the setup of their ISP router to disallow these). Instead, I would like to see that pings to at least one of the gatewayed addresses are allowed (a net-44 address inside one of the subnet(s) routed to that gateway). This is also much more indicative of a functioning gateway. In the IPv6 tunnel example that would mean allowing ping to one IPv6 address. Of course our problem is that we never asked the gateway operators for the address of their gateway on net-44. So that would have to be added in the form, the database and the encap file (or some other file). Rob

1 0

Wiki Content - How many tunnels?
by lleachii＠aol.com 26 May '17

26 May '17

All, It's my understanding that the operating systems we work with only need 1 tunnel, or one system declaration for it. Except those OSes listed under "Non-RIP44 Workarounds", does anyone else run an OS not on the list - that requires you to create more than one (1) tunnel, specify a remote IP other than "Any", or create a route for it before you receive traffic? All I have to do is tell tunl0 to be UP and I'll receive ANYTHING. OPs using other operating systems seem to have configuration differences (maybe that's why they don't understand security concerns). I'm not sure if there's a configuration difference in the Kernels, or what...? 73, - Lynwood KB3VWG

2 1

brave volunteer needed
by Brian Kantor 26 May '17

26 May '17

It looks to me like the new amprgw is working. I'd like to ask for a brave volunteer who is willing to try changing his outgoing route from old amprgw (169.228.66.251) to new amprgw (169.228.34.84) to see if he's able to make connection with the outside world. The return path will still be via old amprgw as we haven't changed the nexthop for 44.0.0.0/8 from oldamprgw to new. If someone would try this and let me know if it worked I'd very much appreciate it. - Brian

2 17

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net