44net

44net@mailman.ampr.org

3196 discussions

Re: [44net] New Linux Boot Scripts for Testing
by Rob Janssen 05 Aug '15

05 Aug '15

> Subject: > Re: [44net] New Linux Boot Scripts for Testing > From: > lleachii(a)aol.com > Date: > 08/04/2015 11:17 PM > > To: > 44net(a)hamradio.ucsd.edu > > > Nigel, > > - I should be a properly configure IPIP gateway. > > Can you reach me? > > 44.60.44.0/24 > 44.60.44.1 - router > 44.60.44.3 - DNS > 44.60.44.10 - HTTP At the time you wrote that it was not yet working, but now I can reach you from here! So it appears you have fixed it. Good! Rob

1 0

Re: [44net] New Linux Boot Scripts for Testing
by Rob Janssen 05 Aug '15

05 Aug '15

> Subject: > Re: [44net] New Linux Boot Scripts for Testing > From: > Tom Hayward <esarfl(a)gmail.com> > Date: > 08/04/2015 09:34 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > On Tue, Aug 4, 2015 at 12:19 PM, Rob Janssen<pe1chl(a)amsat.org> wrote: >>> >>The hamwan.org remain unreachable >> > >> >It goes via radio to our 44.137.0.0/16 gateway and from there over plain >> >internet (it is BGP routed). >> >You may have trouble trying to access this with some of the typical tunnel >> >setups because they provide no tunnel endpoint. > Indeed, this is what you should be seeing for hamwan.org at the > moment. Since our gateway was deleted from the portal we have not gone > in and rebuilt things. > > We are properly BGP routed, so any machine on the internet (and not > behind amprgw) should be able to access it. The system where I tested this (our gateway system) can send internet traffic from 44.137.0.0/16 without source address filtering issues. However, the typical ISP line here is source address filtered, so I cannot send traffic from a 44.137.x.x address directly from my home line to you on your BGP routed network. Traffic to other IPIP gateways is encapsulated in an outer header with my public IP and the public IP of the tunnel endpoint I route to, so my ISP does not filter such traffic. However, when I want to send from my 44.137.x.x address to any other system, either outside 44.x.x.x or in the 44.x.x.x network but not routed via IPIP, I need to encapsulate it and send it to some system that can send that traffic without source address filter. Before we had our own gateway, it was usual to send this traffic to AMPRGW. But that did not work for this case. That appears to have been resolved now. Our own gateway could already do this. However, there is still the issue of "what to do with traffic" (encapsulate it or not, what source address to use) sent to 44.x.x.x. It was difficult to do it right when the tunnel endpoint falls within the 44.x.x.x network. This was the actual reason why your tunnel endpoint was removed after discussion here. I think when you bring back the tunnel endpoint (which of course is preferable), you should try to get an IP outside 44.x.x.x for the tunnel endpoint, as most users have done. That reduces the risk of problems. I do not believe in setting up exception lists for ranges that are BGP routed or are used as tunnel endpoints but are within 44.x.x.x, that is just making everything complicated and makes it break down when people are not always on the watch for changes in the network. The automatic handling provided by (ampr-)ripd is much preferred over such manually maintained configuration. Rob

1 0

Re: [44net] New Linux Boot Scripts for Testing
by Rob Janssen 05 Aug '15

05 Aug '15

> Subject: > Re: [44net] New Linux Boot Scripts for Testing > From: > Gustavo Ponza <g.ponza(a)tin.it> > Date: > 08/05/2015 01:52 AM > > To: > 44net(a)hamradio.ucsd.edu > > > > The following is the routing situation seen from here; the 44.137 IPIP routes > result correctly addressed toward the commercial GW IP addresses according > to the above statements. > The routes are collected from the gw.ampr.org and so only that setup there. > Now, as per my understanding, all the whole 44.137 GWs should be setup > on the same way of that (above) pingable GWs to be reached via tunl0. > > root@ir0rm-7:/# route -n|grep 44.137 > 44.137.2.138 84.106.127.22 255.255.255.255 UGH 0 0 0 tunl0 > 44.137.24.1 88.159.160.228 255.255.255.255 UGH 0 0 0 tunl0 > 44.137.24.5 89.18.172.156 255.255.255.255 UGH 0 0 0 tunl0 > 44.137.25.62 88.159.83.58 255.255.255.255 UGH 0 0 0 tunl0 > 44.137.32.50 84.83.147.249 255.255.255.255 UGH 0 0 0 tunl0 > 44.137.0.49 77.175.246.216 255.255.255.255 UGH 0 0 0 tunl0 > 44.137.40.2 89.18.172.156 255.255.255.255 UGH 0 0 0 tunl0 > 44.137.40.1 89.18.172.156 255.255.255.255 UGH 0 0 0 tunl0 > 44.137.40.10 89.18.172.155 255.255.255.255 UGH 0 0 0 tunl0 > 44.137.40.20 89.18.172.155 255.255.255.255 UGH 0 0 0 tunl0 > 44.137.1.160 46.21.164.170 255.255.255.240 UG 0 0 0 tunl0 > 44.137.1.208 195.240.133.194 255.255.255.240 UG 0 0 0 tunl0 > 44.137.33.16 84.83.147.249 255.255.255.240 UG 0 0 0 tunl0 > 44.137.33.32 62.45.244.128 255.255.255.240 UG 0 0 0 tunl0 > 44.137.51.64 130.255.72.61 255.255.255.240 UG 0 0 0 tunl0 > 44.137.37.160 82.161.55.187 255.255.255.240 UG 0 0 0 tunl0 > 44.137.37.176 82.139.110.195 255.255.255.240 UG 0 0 0 tunl0 > 44.137.37.192 31.151.69.80 255.255.255.240 UG 0 0 0 tunl0 > 44.137.41.128 83.160.55.17 255.255.255.240 UG 0 0 0 tunl0 > 44.137.27.112 88.159.160.228 255.255.255.240 UG 0 0 0 tunl0 > 44.137.31.32 82.176.45.37 255.255.255.240 UG 0 0 0 tunl0 > 44.137.0.0 213.222.29.194 255.255.0.0 UG 0 0 0 tunl0 > >> For example, 44.137.41.97 should be pingable via that endpoint. When doing a traceroute, >> you should see a couple more hops after the tunnel that are radio hops. > > That IP address doesn't appear on the above list but it is positively > pingable That is correct, Gus. The above list except the last line are routes to individuals that are directly on the IPIP tunnel mesh. The last line is a route for everyone in NL that is not on the IPIP mesh, via a gateway system that is both on IPIP and BGP and also routes to radio networks inside the country. The address 44.137.41.97 is on such a radio network, so you get the route to 44.137.0.0 (because it does not appear in the list of more specific entries) and from there via 2 more hops to my station. I think there is no problem with this routing, but the fact that I cannot reach some stations even though all routing is correct is caused by problems with home routers. Some people are behind NAT routers providerd by their ISP, and they have difficulty forwarding the IPIP packets we are using. Some of those routers incorrectly apply stateful firewall rules to (part of) the IPIP incoming traffic. When such a user sends traffic outward, the router puts the temporary rule in place that allows incoming traffic from the tunnel endpoint they route to, and the link works both ways. But when the first traffic is from outside, the IPIP packet never makes it through the router and there is no reply. I have been trying to help a local user who has this problem, and it looks like IPIP is just not possible with them. At least not when the user wants to accept incoming connections. The strange thing is that it appears to work from some systems, and not from others. I have not yet found a clue why this is. Others? Rob

1 0

Scripts
by Steve L 05 Aug '15

05 Aug '15

Well I think maybe Brian Kantor has simplified the IPIP <-> BGP connectivity dilemma for everyone. I was able to ping hamwan.org earlier. It's not working right now, so I'll assume there are some bugs still being worked out. So really what I am about to share may no longer be needed, but I'll share it for informational purposes. Recap: Last month I shared an idea for someone where I had cooked up a way for some hosts on his RF LAN to be reachable via UCSD, and the rest masq'd. http://www.qsl.net/kb9mwr/wapr/tcpip/startampr-n3fe To which PE1CHL replied he does something similar, but he use the mark to enable the masquerading So that got me thinking maybe this same concept could be applied to the BGP'd subnets, forcing them to use masquerading. But rather a rule on the source address, we set it for destinations. Here is what I came up with. (Untested) http://www.qsl.net/kb9mwr/wapr/tcpip/startampr-bgp Basically I download a list of all the BGP'd subnets, and set a flag like before and force them out as masqueraded.

1 0

Re: [44net] New Linux Boot Scripts for Testing
by Rob Janssen 05 Aug '15

05 Aug '15

> Subject: > Re: [44net] New Linux Boot Scripts for Testing > From: > Gustavo Ponza <g.ponza(a)tin.it> > Date: > 08/04/2015 02:10 PM > > To: > 44net(a)hamradio.ucsd.edu > > > As per the 44.88.0.9: > > As per my tests since this morning (local time) for the first time > I can ping and connect the http and ftp facilities at 44.88.0.9 and > downloaded some files... never happened since years to now!!! > Hope that Brian will share his actual GW setup, TNX. > > As per the 44.137.0.1 and subnets: > > Report is that the 44.137.0.1 GW is promptly pingable, but regarding > their subnet only the following are *correctly* pingable, namely: > > 44.137.24.5 > 44.137.40.1 > 44.137.40.10 > 44.137.40.2 > 44.137.40.20 > > all the other not. Those addresses are not on the 44.137.0.1 gateway but on two different private gateway systems that advertise only those addresses. I hope everyone correctly implements a "most specific route first" policy that means that traffic to such addresses goes to the indicated tunnel endpoint (89.18.172.155 and 89.18.172.156) while other addresses in the 44.137.0.0/16 network are routed to tunnel endpoint 213.222.29.194. That should be no problem on e.g. a Linux system. For example, 44.137.41.97 should be pingable via that endpoint. When doing a traceroute, you should see a couple more hops after the tunnel that are radio hops. > > As per the 44.60.44.10: > > Remain not pingable > Same for me! > The hamwan.org remain unreachable That one is reachable for me: traceroute hamwan.org traceroute to hamwan.org (44.24.241.98), 30 hops max, 60 byte packets 1 gw.pe1chl.ampr.org (44.137.41.110) 0.248 ms 0.337 ms 0.428 ms 2 cisco1.pi1utr.ampr.org (44.137.41.254) 2.254 ms 20.621 ms 21.124 ms 3 pi1utr.pi9noz.ampr.org (44.137.60.1) 22.615 ms 34.658 ms 34.694 ms 4 213.222.29.193 (213.222.29.193) 68.524 ms 68.560 ms 68.582 ms 5 0.xe-7-0-1.xr4.1d12.xs4all.net (194.109.12.5) 68.636 ms 70.600 ms 71.415 ms 6 0.ge-0-2-0.xr1.sara.xs4all.net (194.109.5.2) 73.308 ms 77.651 ms 77.645 ms 7 er1.ams1.nl.above.net (80.249.208.122) 79.347 ms 64.952 ms 11.503 ms 8 ae14.cr1.ams10.nl.zip.zayo.com (64.125.21.77) 13.982 ms 14.622 ms 15.123 ms 9 v142.ae29.cr2.ord2.us.zip.zayo.com (64.125.30.170) 112.583 ms 112.614 ms 113.365 ms 10 ae11.cr1.ord2.us.zip.zayo.com (64.125.20.245) 118.816 ms 119.403 ms 120.093 ms 11 v11.ae29.mpr1.sea1.us.zip.zayo.com (64.125.31.50) 158.630 ms 159.681 ms 160.046 ms 12 216.200.88.129.z00003.above.net (216.200.88.129) 159.559 ms 159.593 ms 159.922 ms 13 ge0-0-0-0-sea4.threshinc.net (209.189.201.214) 150.858 ms ge0-0-0-0-sea3.threshinc.net (209.189.201.213) 151.354 ms ge0-0-0-1-sea3.threshinc.net (209.189.202.213) 151.977 ms 14 seattle-er1.hamwan.net (209.189.196.68) 152.033 ms 150.810 ms 151.959 ms 15 eth0.seattle-srv1.hamwan.net (44.24.241.98) 149.933 ms 150.508 ms 151.199 ms It goes via radio to our 44.137.0.0/16 gateway and from there over plain internet (it is BGP routed). You may have trouble trying to access this with some of the typical tunnel setups because they provide no tunnel endpoint. Rob

5 7

Re: [44net] 44Net Digest, Vol 4, Issue 115
by lleachii＠aol.com 05 Aug '15

05 Aug '15

Apologies, I meant to send the last email to my local ARES/RACES reflector regarding National Night Out. - Lynwood

1 0

Re: [44net] 44Net Digest, Vol 4, Issue 115
by lleachii＠aol.com 05 Aug '15

05 Aug '15

County Exec last spotted in Upper Marlboro, I didn't have reception. - Lynwood KB3VWG

1 0

Re: [44net] DMARC
by Brian Kantor 04 Aug '15

04 Aug '15

Well, if I did everything right, the people on yahoo, comcast, and sbcglobal who weren't getting messages from this mailing list because of those ISPs' DMARC filtering should now be getting messages once again. - Brian

3 4

DMARC
by Brian Kantor 04 Aug '15

04 Aug '15

It appears that comcast and yahoo have implemented DMARC mail filtering around the first of the month. This breaks mailing lists such as 44net. As a result, about a dozen people have had their mail from this list bouncing and they've been unsubscribed from the list as a result. This message won't reach them, but if you happen to hear from a former participant in this list who is wondering what happened, you might let them know that their ISP has broken mail filtering software in place that is blocking their participation. - Brian

2 4

test header munging
by Brian Kantor 04 Aug '15

04 Aug '15

testing header munging for DMARC

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net