Can everyone verify their AMRPRNet tunl0 route tables do not include the following value: "proto 44" This appears to have somehow entered some stations routing tables, the value should be "table 44" for routers using a separate routing table, as defined in STARTAMPR; or by using '-t' switch with RIP44d. The ROUTING PROTOCOL value "proto 44" is invalid for routing on AMPRNet, and I understand it should be zero (0) or unspecified. - Lynwood KB3VWG

The 'proto 44' you see listed by the 'ip route list' is an internal netlink identificator and has nothing to do with the protocol on the network. It is used by ampr-ripd to identify the routes set by itself, to be able to avoid altering other routes set by other tools, and has no other meaning. Marius, YO2LOJ -----Original Message----- From: 44net-bounces+marius=yo2loj.ro(a)hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of lleachii(a)aol.com Sent: Sunday, August 02, 2015 23:48 To: 44net(a)hamradio.ucsd.edu Subject: Re: [44net] New Linux Boot Scripts for Testing (Please trim inclusions from previous messages) _______________________________________________ Can everyone verify their AMRPRNet tunl0 route tables do not include the following value: "proto 44" This appears to have somehow entered some stations routing tables, the value should be "table 44" for routers using a separate routing table, as defined in STARTAMPR; or by using '-t' switch with RIP44d. The ROUTING PROTOCOL value "proto 44" is invalid for routing on AMPRNet, and I understand it should be zero (0) or unspecified. - Lynwood KB3VWG _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

All, OK, I've taken a look at my end, please test again, I found two issues: - there was a phantom iptables rule preventing all outbound on the unencapsulated Public IP - In the new script, I failed to properly add the rules for LANs on eth0. There should be a to and from rule to the network located on eth0: TO ip rule to <LAN/24> priority 10 ip rule from <LAN/24> priority 11 This rule must exist, exactly as noted. it should not specify a from/to your 44LAN. - Lynwood

Marius, I'm seeing odd behavior when I traceroute to you. My traffic destined for you is encapsulated properly, but (unless I need a valid IP), the packets seem to leave you unenscapsulated (perhaps using Masquerade NAT???) and travel toward the Main AMPR Gateway: - first, I verified my route user@kb3vwg-001:~$ ip route get 44.182.0.0 44.182.0.0 via 89.122.215.236 dev tunl0 src 44.60.44.2 cache window 840 - next, that source and destination would use the proper table: user@kb3vwg-001:~$ ip rule show 0: from all lookup local 10: from all to 192.168.0.0/16 lookup main 11: from 192.168.0.0/16 lookup main 15: from all to 44.24.221.1 lookup main ****FROM YOU*** 22: from all to 44.60.44.0/24 lookup 42 **** 43: from all to 44.24.240.0/20 lookup 43 ****TO YOU***44: from all to 44.0.0.0/8 lookup 44 *** 45: from 44.0.0.0/8 lookup 44 4400: from 44.60.44.0/24 lookup 40 7777: from all to 44.0.0.0/8 lookup 7777 7778: from 44.0.0.0/8 lookup 7777 32766: from all lookup main 32767: from all lookup default - finally, I traceroute from my tunnel: user@kb3vwg-001:~$ traceroute 44.182.0.12 -s 44.60.44.2 traceroute to 44.182.0.12 (44.182.0.12), 30 hops max, 60 byte packets 1 * * * !*!*!*!*!* 2 89.122.214.254 (89.122.214.254) 156.075 ms 157.348 ms 158.606 ms !*!*!*!*!* 3 10.0.225.49 (10.0.225.49) 160.229 ms 161.495 ms 162.890 ms 4 10.0.245.209 (10.0.245.209) 186.365 ms 188.425 ms 191.056 ms 5 10.0.200.138 (10.0.200.138) 192.674 ms 194.866 ms 196.200 ms 6 193.231.106.82 (193.231.106.82) 197.768 ms 175.030 ms 175.328 ms 7 tge1-2.fr4.ams.llnw.net (69.28.171.54) 185.121 ms 185.355 ms 177.489 ms 8 tge2-6.fr4.lga.llnw.net (69.28.189.49) 261.977 ms 260.528 ms 269.815 ms 9 tge1-2.fr4.ord.llnw.net (69.28.172.198) 287.947 ms 288.808 ms 285.129 ms 10 tge1-3.fr4.sjc.llnw.net (69.28.172.77) 345.404 ms 346.292 ms 329.787 ms 11 paix-px1--limelight-10ge.cenic.net (198.32.251.193) 335.805 ms 327.859 ms * 12 dc-lax-agg6--svl-agg4-100ge.cenic.net (137.164.11.0) 338.919 ms dc-svl-agg4--paix-px1-10g.cenic.net (137.164.47.21) 326.279 ms 332.317 ms 13 dc-riv-agg4--lax-agg6-100ge.cenic.net (137.164.11.3) 337.663 ms dc-lax-agg6--svl-agg4-100ge.cenic.net (137.164.11.0) 340.068 ms dc-riv-agg4--lax-agg6-100ge.cenic.net (137.164.11.3) 344.378 ms 14 dc-sdg-agg4--riv-agg4-10ge-2.cenic.net (137.164.47.15) 345.599 ms dc-riv-agg4--lax-agg6-100ge.cenic.net (137.164.11.3) 344.061 ms dc-sdg-agg4--riv-agg4-10ge.cenic.net (137.164.47.111) 344.344 ms 15 dc-sdg-agg4--riv-agg4-10ge-2.cenic.net (137.164.47.15) 352.518 ms dc-sdg-agg4--riv-agg4-10ge.cenic.net (137.164.47.111) 344.658 ms 352.857 ms 16 nodem-core--mx0-30ge.ucsd.edu (132.239.254.163) 339.536 ms dc-ucsd-1--sdg-agg4.cenic.net (137.164.23.54) 347.626 ms nodem-core--mx0-30ge.ucsd.edu (132.239.254.163) 341.363 ms 17 nodem-core--mx0-30ge.ucsd.edu (132.239.254.163) 414.562 ms ebu3b-6509-nodem-core-interconnect-vl910-bcast-255-131.ucsd.edu (132.239.255.131) 345.084 ms nodem-core--mx0-30ge.ucsd.edu (132.239.254.163) 387.159 ms 18 ebu3b-6509-nodem-core-interconnect-vl910-bcast-255-131.ucsd.edu (132.239.255.131) 350.108 ms 347.151 ms amprgw.sysnet.ucsd.edu (169.228.66.251) 348.789 ms 19 amprgw.sysnet.ucsd.edu (169.228.66.251) 342.078 ms 341.454 ms * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * It appears the traffic is entering your device, and then travling onward to the Main AMPR Gateway. I verified the traffic is encapsulated, by using Wireshark to monitor the line. - Lynwood KB3VWG

Lynwood, Thank you for pointing out the issue. It allowed unknown traffic coming from ampr machines to reach the GW, which is wrong. I corrected it in the firewall rules. Anyway, this should not prevent my gw from working. As I said, you can traceroute 44.182.21.1, 44.182.21.254 or 44.182.30.1 (the later not always up). Could you please check again? Ttrace to 44.182.0.12 should die at hop 1 without forwarding. -----Original Message----- From: 44net-bounces+marius=yo2loj.ro(a)hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of lleachii(a)aol.com Sent: Tuesday, August 04, 2015 16:00 To: 44net(a)hamradio.ucsd.edu Subject: Re: [44net] New Linux Boot Scripts for Testing (...) - finally, I traceroute from my tunnel: user@kb3vwg-001:~$ traceroute 44.182.0.12 -s 44.60.44.2 traceroute to 44.182.0.12 (44.182.0.12), 30 hops max, 60 byte packets 1 * * * !*!*!*!*!* 2 89.122.214.254 (89.122.214.254) 156.075 ms 157.348 ms 158.606 ms !*!*!*!*!* 3 10.0.225.49 (10.0.225.49) 160.229 ms 161.495 ms 162.890 ms 4 10.0.245.209 (10.0.245.209) 186.365 ms 188.425 ms 191.056 ms 5 10.0.200.138 (10.0.200.138) 192.674 ms 194.866 ms 196.200 ms 6 193.231.106.82 (193.231.106.82) 197.768 ms 175.030 ms 175.328 ms 7 tge1-2.fr4.ams.llnw.net (69.28.171.54) 185.121 ms 185.355 ms 177.489 ms (...)

Correction, the full command is: ip tunnel change ttl 64 mode ipip tunl0 - Lynwood

Lynwood, This has been discussed innumerable times here on this list, where myself and other BGP subnet operators have weighed in. 1. Some IPIP users route 44/8 through amprgw. Now that amprgw can reach us, this fixes their connectivity issues. 2. IPIP users who route properly by NATing out 44-net subnets that they don't have an IPIP tunnel for will reach us fine, and could reach us before. This is not a matter of what the source IP is. This is a matter of amprgw could not reach non-IPIP subnets prior to now. Now it can, and traffic flowing through it can as well. If an IPIP operator wants to *not* NAT out 44-net subnets that are *not* in the IPIP mesh and not have a default 44/8 route through amprgw, then they have no route, and can't reach us anyway. Nigel K7NVH

Lynwood, So, you are still reachable only via internet since there is no reply on requests via your tunnel.. Could you provide access to the script via internet (I would really see it - private mail is out of scope since aol does not like my provider...)? In fact if someone can reach your network via AMPR, than he has a working setup and doesn't need that script anymore, isn't it ;-) Marius, YO2LOJ -----Original Message----- From: 44net-bounces+marius=yo2loj.ro(a)hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of lleachii(a)aol.com Sent: Wednesday, August 05, 2015 00:18 To: 44net(a)hamradio.ucsd.edu Subject: Re: [44net] New Linux Boot Scripts for Testing ... Also, if you could look ay my script? Is it properly configured to reach your subnet? http://44.60.44.10/amprnet_docs/start_ampr_version2/startampr ...

Lynwood, Please feel free to use my router at 44.12.6.1 to test against. It will respond to pings and reject UDP to show up in a traceroute. It is BGP announced only, and works properly from the public internet, and can reach AMPRGW. Nigel K7NVH

Nigel, user@kb3vwg-001:/usr/local/sbin$ ip route get 44.12.6.1 from 44.60.44.2 44.12.6.1 from 44.60.44.2 via 169.228.66.251 dev tunl0 cache This appears to be correct, as you mentioned: "This is not a matter of what the source IP is. This is a matter of amprgw could not reach non-IPIP subnets prior to now. Now it can, and traffic flowing through it can as well." I'm unable to ping or traceroute. When you mention: "It is BGP announced only, and works properly from the public internet, and can reach AMPRGW..." do you mean you're running an IPIP tunnel, or some other way of forwarding packets destined to 44.60.44.0/24, BACK to AMPRGW, or directly to me??? - Lynwood KB3VWG

Hi Lynwood and all, the latest lessons learned specially from Tom and Rob concern and imply the standard use of the IPIP encap tunnels (i.e. tunl0) to effectively link the other, BGP-announced or not, gateways or amprnets and the amprgw at ucsd.edu/portal.ampr.org. Adding all BGP routes are not effective being from here, on my site. Quote from Tom: so, it is impossible, for now, access the hamwan.org being behind amprgw, as explained. gus

Hi Tom, Confirm again the no-reachability from here :( root@ir0rm-7:/# ping HamWAN.org -c 5 PING hamwan.org (44.24.241.98) 56(84) bytes of data. --- hamwan.org ping statistics --- 5 packets transmitted, 0 received, 100% packet loss, time 3999ms gus

Stop there! All your 44 IPs are pingable and services become accessible:) root@ir0rm-7:/# ping 44.60.44.1 PING 44.60.44.1 (44.60.44.1) 56(84) bytes of data. 64 bytes from 44.60.44.1: icmp_req=1 ttl=64 time=293 ms 64 bytes from 44.60.44.1: icmp_req=2 ttl=64 time=290 ms 64 bytes from 44.60.44.1: icmp_req=3 ttl=64 time=291 ms 64 bytes from 44.60.44.1: icmp_req=4 ttl=64 time=292 ms 64 bytes from 44.60.44.1: icmp_req=5 ttl=64 time=293 ms 64 bytes from 44.60.44.1: icmp_req=6 ttl=64 time=290 ms ^C --- 44.60.44.1 ping statistics --- 6 packets transmitted, 6 received, 0% packet loss, time 5001ms rtt min/avg/max/mdev = 290.542/292.077/293.782/1.495 ms root@ir0rm-7:/# ping 44.60.44.10 PING 44.60.44.10 (44.60.44.10) 56(84) bytes of data. 64 bytes from 44.60.44.10: icmp_req=1 ttl=63 time=292 ms 64 bytes from 44.60.44.10: icmp_req=2 ttl=63 time=292 ms 64 bytes from 44.60.44.10: icmp_req=3 ttl=63 time=292 ms 64 bytes from 44.60.44.10: icmp_req=4 ttl=63 time=293 ms 64 bytes from 44.60.44.10: icmp_req=5 ttl=63 time=291 ms ^C --- 44.60.44.10 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4004ms rtt min/avg/max/mdev = 291.261/292.501/293.274/0.826 ms root@ir0rm-7:/#

On Wed, Aug 5, 2015 at 3:53 PM, lleachii--- via 44Net &lt;44net(a)hamradio.ucsd.edu&gt; wrote: Brian, Is there a rule on amprgw that blocks forwarding packets between 44 networks? I have heard discussion of such a rule in the past. The intent, as I understood it, was to require IPIP users to use the full mesh routes rather than relying on amprgw to act as a hub. If this rule in implemented on 44/8, it will blackhole BGP networks who don't take part in the mesh. (Maybe this was the intent?) Tom KD7LXL

Testing shows that traffic between encap'd and BGP'd subnets of network 44 is now possible. There was a bug in the ipfw rules that fed the encapsulator that has been corrected and it seems to work now. - Brian

Nigel, please try the ping and traceroute to 44.134.32.240 and 44.134.32.233 gus

On 08/07/2015 01:37 PM, Brian Kantor wrote: Those addresses are not routed externally to ampr.org environment and so remain unknown as commercial/public addresses on the Internet. Just checked the home router setup and found enabled the "SPI Firewall Protection" and "Block Anonymous internet requests"; now they are disabled and furthermore confirm no other access restricting are enabled now. gus

Gus, Your route setup seems ok, but please note that your host IP (44.134.32.240) needs to be registered in the AMPR DNS to be forwarded by AMPRGW. If those conditions are met and it still doesn't work, please provide a traceroute from your gateway to hamwan.org maybe we can see what's wrong. Marius, YO2LOJ

confirmed by Brian The traceroute to hamwan.org persists to show empty tracks: root@ir0rm-7:/# traceroute hamwan.org traceroute to hamwan.org (44.24.241.98), 30 hops max, 60 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * root@ir0rm-7:/# gus

John, Yes, you should be able to send encapsulated data via amprgw and get the correct replies, but only for specific BGP announced and registered subnets. Arbitrary 44net targets not in those BGP announced networks are NOT forwarded via amprgw, and only DNS registered hosts will be able to use the gateway (as you correctly assume). Hosts with no DNS entries can only use the IPIP mesh system, since there is usually no check for that criteria on the gateways, and any subnet match is accepted. Marius, YO2LOJ

The design is indeed perfect but the practice reveals some faults. Tests made on the latest days from here at 'ir0rm-7.ampr.org' towards the about 480 ampr hosts reveal that a lot of gateways under amprgw cannot be reached due to perhaps wrong or super-genius faulty setups. Some tests, as known, gave the right results after some modification to their setups: so it is demonstrated that the amprgw and the RIP2 broadcast hosts operate correctly. So as per my motto recommend "the simpler, the better". TNX for the info. On this purpose, I discovered that *all* the reachable hosts like as per the following example show the same hidden path from position 1 to position 11 so it is a mystery the track/path followed. Furthermore the 44.0.0.1 like the hamwan.org results not pingable and then not traceable. gus ----------------- root@ir0rm-7:# traceroute n1uro.ampr.org traceroute to n1uro.ampr.org (44.88.0.9), 30 hops max, 60 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 n1uro.ampr.org (44.88.0.9) 346.790 ms 346.975 ms 351.388 ms

Unfortunately not, Brian. Replies are the following gus ----------------- root@ir0rm-7:# ping hamwan.org -c 5 PING hamwan.org (44.24.241.98) 56(84) bytes of data. --- hamwan.org ping statistics --- 5 packets transmitted, 0 received, 100% packet loss, time 3999ms root@ir0rm-7:# ping wr6jpl.ampr.org -c 5 PING wr6jpl.ampr.org (44.16.15.5) 56(84) bytes of data. --- wr6jpl.ampr.org ping statistics --- 5 packets transmitted, 0 received, 100% packet loss, time 3999ms root@ir0rm-7:# traceroute hamwan.org traceroute to hamwan.org (44.24.241.98), 30 hops max, 60 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * root@ir0rm-7:# traceroute wr6jpl.ampr.org traceroute to wr6jpl.ampr.org (44.16.15.5), 30 hops max, 60 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * root@ir0rm-7:# ----------------

Another lesson learned: very TNX Marius! From here now it results: traceroute to n1uro.ampr.org (44.88.0.9), 30 hops max, 60 byte packets 1 gw.ct.ampr.org (44.88.0.1) 169.293 ms 175.416 ms 175.593 ms 2 n1uro.ampr.org (44.88.0.9) 180.007 ms * * gus

All, For your information, my colleague Tom was kind enough to write a tool that should let you run traceroutes from our network. If you can’t reach us via 44-net, you’ll obviously need to access via public internet. http://trace.hamwan.net/ <http://trace.hamwan.net/> Feel free to use it to test if you’re reachable from BGP announced subnets like ours. Nigel K7NVH > On Aug 7, 2015, at 06:51, lleachii--- via 44Net &lt;44net(a)hamradio.ucsd.edu&gt; wrote: > > (Please trim inclusions from previous messages) > _______________________________________________ > > Gus, > > I had errors and collisions before I reviewed my configuration. Now that's everything properly configured, I don't see them. > > It may be helpful to note the only TWO reasons the collision and error count increases on a tunnel interface: > > > > If the next hop of the encapsulated packet is the same tunnel interface: ipip.c line 437. > > If the path MTU of the next hop for the encapsulated packet is less than 68:ipip.c line 447. > > > > > - Lynwood > > > > -----Original Message----- > note that (I'm not aware why) on the tunl0 interface there are > many errors/collisions on the TX tunnel side. > > >

Lynwood, my tunl0 interface shows the following values: tunl0 Link encap:IPIP Tunnel HWaddr inet addr:44.134.32.240 Mask:255.0.0.0 UP RUNNING NOARP MULTICAST MTU:1480 Metric:1 RX packets:827174 errors:0 dropped:0 overruns:0 frame:0 TX packets:50426 errors:757836 dropped:0 overruns:0 carrier:0 collisions:757836 txqueuelen:0 RX bytes:75933090 (72.4 Mb) TX bytes:4817617 (4.5 Mb) I'm not able to analyze what kinda packets are concerned on producing collisions... gus On 08/07/2015 03:51 PM, lleachii--- via 44Net wrote: > (Please trim inclusions from previous messages) > _______________________________________________ > > Gus, > > I had errors and collisions before I reviewed my configuration. Now that's everything properly configured, I don't see them. > > It may be helpful to note the only TWO reasons the collision and error count increases on a tunnel interface: > > > > If the next hop of the encapsulated packet is the same tunnel interface: ipip.c line 437. > > If the path MTU of the next hop for the encapsulated packet is less than 68:ipip.c line 447. > > > > > - Lynwood > > > > -----Original Message----- > note that (I'm not aware why) on the tunl0 interface there are > many errors/collisions on the TX tunnel side. > > >

I've also restored my ping and traceroute programs. You'll now find four tools: ping ping44 trace trace44 ping/trace44 uses my AMPR IP address, ping uses my gateway's commercial IP. - Lynwood

What model?

El 13/08/15 a las 01:33, lleachii--- via 44Net escribió: Dear Lynwood, I have an OpenWRT router running as my AMPR/Hamnet gateway at router.ea4gpz.es.ampr.org. I have ampr-ripd on it. I installed it a while ago, so I don't recall the details of how I cross-compiled it, but I guess that, being a simple C file it would be enough to just set up a cross-compiler and not the whole OpenWRT buildchain. My router happens to be PPC instead of the more common MIPS. If your router is also PPC by chance, then I can send you the ampr-ripd binary to save you the process of cross-compiling. My script to start the tunnel and ampr-ripd goes like this: ------------- ip tunnel add ampr0 mode ipip local 88.26.246.131 ttl 255 ip link set dev ampr0 up ifconfig ampr0 multicast ifconfig ampr0 44.133.28.155 netmask 255.255.255.255 ip rule add from 44.133.28.155 to 44.0.0.0/8 table 44 priority 5 ip route add default dev ampr0 via 169.228.66.251 onlink table 44 /root/ampr-ripd -s -i ampr0 -a 88.26.246.131 -t 44 -p pLaInTeXtpAsSwD ----------------- Probably you would want to change the rules to route via table 44, which in my case are custom because there is both Hamnet and ampr-ripd routing at the site. The script is mainly taken from the ampr wiki. It seems to me that, apart from ampr-ripd, the only packages you need installed are ip and kmod-ipip, which I don't know if they come installed by default or not. I hope you find this info useful. 73, Dani EA4GPZ.

Who makes it? Sounds useful. What is the link to purchase one on Amazon?

I've also noticed another anomaly. I recently switched to Verizon from Comcast, and began using their border device: Three times I've noticed that when I'm using their FiOS Quantum Gateway - model G1100, that port forwardings for ICMP-Echo-Request and IPENCAP have disappeared from my forwarding table. I cannot be certain why; but I will be removing their device from my border later today. It should also be noted that Verizon has access to their border devices; so I'll be rectifying that today. - Lynwood

Test 2

Lynwood, Your system does the encapsulation wrong. If I ping it via the tunnel to 96.255.40.79, the reply are returned ipip encapsulated from ucsd (169.228.66.251) instead of having been originated from 96.255.40.79, and thus get dropped by most systems which expects the same endpoints for responses. Return/outgoing traffic from your system has to be originated from your GW address and sent directly to the recipient, according to the encap table, not via the gateway. Marius, YO2LOJ -----Original Message----- From: 44net-bounces+marius=yo2loj.ro(a)hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Gustavo Ponza Sent: Monday, August 03, 2015 10:02 To: 44net(a)hamradio.ucsd.edu Subject: Re: [44net] New Linux Boot Scripts for Testing (Please trim inclusions from previous messages) _______________________________________________ No link from here to your address... but this fault remain the same, as normal, for several other sites i.e. N1URO, etc. Setup here is the standard IPIP tunnel (tunl0) on 44.134.32.240 IP address and ampr-ripd v 1.13 with any kinda filters used. As per other previous messages: I can confirm to Brian Kantor the very good setup of RIP2 service at ucsd.edu server for the *RIP time/rate broadcast* and for the very *short reaction* on portal.ampr.org when a dynamic IP address change occurs. Very TNX. 73, gus i0ojj _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net