Today I tried to access a number of 44.x.x.x/8 web sites that I was perfectly able to access a week ago, but cannot tonight. A "traceroute" shows that these accesses are leaving the 44.x.x.x/8 network and coming back in at UCSD. That of course could explain what is happening.
Can you give an example of something you were trying to access that's giving you issues? Nigel K7NVH On Mar 27, 2014, at 9:30 PM, Dean Gibson AE7Q <hamwan@ae7q.net> wrote:
Today I tried to access a number of 44.x.x.x/8 web sites that I was perfectly able to access a week ago, but cannot tonight. A "traceroute" shows that these accesses are leaving the 44.x.x.x/8 network and coming back in at UCSD. That of course could explain what is happening.
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
I saw -69 dB at Yukon Harbor Road and Colchester Road this evening at 1730. The link was to Capitol Park; azimuth was approximately 48 degrees. Callsign is KD7WDJ (Kitsap County Alternate Communications System). More shots tomorrow from Kitsap County. 73, Dan at K7MM 509.330.6398
On Mar 27, 2014, at 22:29, Nigel Vander Houwen <nigel@k7nvh.com> wrote:
Can you give an example of something you were trying to access that's giving you issues?
Nigel K7NVH
On Mar 27, 2014, at 9:30 PM, Dean Gibson AE7Q <hamwan@ae7q.net> wrote:
Today I tried to access a number of 44.x.x.x/8 web sites that I was perfectly able to access a week ago, but cannot tonight. A "traceroute" shows that these accesses are leaving the 44.x.x.x/8 network and coming back in at UCSD. That of course could explain what is happening.
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
That's surprising given all the city scape in the way. Right on. --Bart On 3/27/2014 10:45 PM, Dan Ransom, PE wrote:
I saw -69 dB at Yukon Harbor Road and Colchester Road this evening at 1730. The link was to Capitol Park; azimuth was approximately 48 degrees. Callsign is KD7WDJ (Kitsap County Alternate Communications System).
More shots tomorrow from Kitsap County.
73,
Dan at K7MM 509.330.6398
Awesome! Try some other directions, if you can. Mirrormont and Baldi are probably also accessible from there. Give me a call on 147.30+ (88.5) if you need any help. Tom KD7LXL On Mar 27, 2014 10:45 PM, "Dan Ransom, PE" <danra995@yahoo.com> wrote:
I saw -69 dB at Yukon Harbor Road and Colchester Road this evening at 1730. The link was to Capitol Park; azimuth was approximately 48 degrees. Callsign is KD7WDJ (Kitsap County Alternate Communications System).
More shots tomorrow from Kitsap County.
73,
Dan at K7MM 509.330.6398
On Mar 27, 2014, at 22:29, Nigel Vander Houwen <nigel@k7nvh.com> wrote:
Can you give an example of something you were trying to access that's giving you issues?
Nigel K7NVH
On Mar 27, 2014, at 9:30 PM, Dean Gibson AE7Q <hamwan@ae7q.net> wrote:
Today I tried to access a number of 44.x.x.x/8 web sites that I was perfectly able to access a week ago, but cannot tonight. A "traceroute" shows that these accesses are leaving the 44.x.x.x/8 network and coming back in at UCSD. That of course could explain what is happening.
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
Tom, I pointed to 120 degrees and I think that I got a signal....then, my modem "went away." It disconnected from WinBox. I had to go pick up my wife, so I did not pursue it further. Did the cache bug bite me? 23. OPTIONAL: Work around a RouterOS route cache bug until it's fixed upstream 73 from Dan at K7MM 145.430 - 179.9 509 330 6398 ________________________________ From: Tom Hayward <esarfl@gmail.com> To: Puget Sound Data Ring <psdr@hamwan.org> Sent: Friday, March 28, 2014 8:56 AM Subject: Re: [HamWAN PSDR] Manchester, WA Test Good Awesome! Try some other directions, if you can. Mirrormont and Baldi are probably also accessible from there. Give me a call on 147.30+ (88.5) if you need any help. Tom KD7LXL On Mar 27, 2014 10:45 PM, "Dan Ransom, PE" <danra995@yahoo.com> wrote: I saw -69 dB at Yukon Harbor Road and Colchester Road this evening at 1730. The link was to Capitol Park; azimuth was approximately 48 degrees. Callsign is KD7WDJ (Kitsap County Alternate Communications System).
More shots tomorrow from Kitsap County.
73,
Dan at K7MM 509.330.6398
On Mar 27, 2014, at 22:29, Nigel Vander Houwen <nigel@k7nvh.com> wrote:
Can you give an example of something you were trying to access that's giving you issues?
Nigel K7NVH
On Mar 27, 2014, at 9:30 PM, Dean Gibson AE7Q <hamwan@ae7q.net> wrote:
Today I tried to access a number of 44.x.x.x/8 web sites that I was perfectly able to access a week ago, but cannot tonight. A "traceroute" shows that these accesses are leaving the 44.x.x.x/8 network and coming back in at UCSD. That of course could explain what is happening.
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
No, the route cache bug takes a few weeks to manifest, and only on routers running OSPF, which yours isn't. The only non-transient error I can think of that would match what you describe is an IP address issue. When your modem associates with the sector, it is assigned an IP address on the wireless interface by DHCP. Depending on how you're connecting to the modem, maybe the IP address you were connected to was removed. I'd recommend connecting via MAC address to avoid this type of thing. To do that, you click on the three dots in the Winbox connection dialog. It will bring up a window that lists all the Mikrotik devices found on the local network. There will be multiple columns, including MAC address and IP address. If you click the MAC address, it will auto-fill the connection dialog with the MAC address and connect via layer 2. What is your wireless MAC address? I'll watch for it in the sector logs. Tom On Fri, Mar 28, 2014 at 11:35 AM, Daniel Ransom <danra995@yahoo.com> wrote:
Tom,
I pointed to 120 degrees and I think that I got a signal....then, my modem "went away." It disconnected from WinBox. I had to go pick up my wife, so I did not pursue it further.
Did the cache bug bite me? 23. OPTIONAL: Work around a RouterOS route cache bug until it's fixed upstream
73 from Dan at K7MM
145.430 - 179.9 509 330 6398
________________________________ From: Tom Hayward <esarfl@gmail.com> To: Puget Sound Data Ring <psdr@hamwan.org> Sent: Friday, March 28, 2014 8:56 AM Subject: Re: [HamWAN PSDR] Manchester, WA Test Good
Awesome! Try some other directions, if you can. Mirrormont and Baldi are probably also accessible from there. Give me a call on 147.30+ (88.5) if you need any help. Tom KD7LXL On Mar 27, 2014 10:45 PM, "Dan Ransom, PE" <danra995@yahoo.com> wrote:
I saw -69 dB at Yukon Harbor Road and Colchester Road this evening at 1730. The link was to Capitol Park; azimuth was approximately 48 degrees. Callsign is KD7WDJ (Kitsap County Alternate Communications System).
More shots tomorrow from Kitsap County.
73,
Dan at K7MM 509.330.6398
On Mar 27, 2014, at 22:29, Nigel Vander Houwen <nigel@k7nvh.com> wrote:
Can you give an example of something you were trying to access that's giving you issues?
Nigel K7NVH
On Mar 27, 2014, at 9:30 PM, Dean Gibson AE7Q <hamwan@ae7q.net> wrote:
Today I tried to access a number of 44.x.x.x/8 web sites that I was perfectly able to access a week ago, but cannot tonight. A "traceroute" shows that these accesses are leaving the 44.x.x.x/8 network and coming back in at UCSD. That of course could explain what is happening.
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
I currently can't connect to *ANY* in the list (someone else gave me as valid) below. Previously (about a week ago), I only tried a few in the list below, but those connected. A DNS lookup today on a few of them, returns an address in the 44 block, so I doubt it's DNS. Here's a "traceroute" to 44.225.56.72 (in the list below): / traceroute to 44.225.56.72 (44.225.56.72), 30 hops max, 38 byte packets 1 5shpn-1_ext (192.168.3.251) 0.437 ms 0.255 ms 0.237 ms 2 44.24.240.161 (44.24.240.161) 56.927 ms 66.802 ms 10.479 ms 3 44.24.240.136 (44.24.240.136) 5.019 ms 26.476 ms 8.432 ms 4 44.24.242.7 (44.24.242.7) 37.010 ms 31.064 ms 8.447 ms 5 44.24.242.4 (44.24.242.4) 49.188 ms 64.406 ms 51.113 ms 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * */ On 2014-03-27 22:29, Nigel Vander Houwen wrote:
Can you give an example of something you were trying to access that's giving you issues?
Nigel K7NVH
On Mar 27, 2014, at 9:30 PM, Dean Gibson AE7Q <hamwan@ae7q.net> wrote:
Today I tried to access a number of 44.x.x.x/8 web sites that I was perfectly able to access a week ago, but cannot tonight. A "traceroute" shows that these accesses are leaving the 44.x.x.x/8 network and coming back in at UCSD. That of course could explain what is happening.
/ http://web.db0avh.ampr.org http://db0bi.ampr.org http://db0dah.ampr.org http://db0eeo.ampr.org http://db0end.ampr.org http://db0fhn.ampr.org http://db0res-svr.ampr.org http://db0gos.ampr.org http://db0dz.ampr.org http://db0ii.ampr.org http://db0iuz.ampr.org http://44.225.56.72/cms25 http://db0kwe.ampr.org http://srv.db0lj.ampr.org http://db0nis.ampr.org http://db0ovn.ampr.org http://44.225.60.2 http://db0sda.ampr.org http://db0ach.ampr.org http://db0pra.ampr.org http://websrv.db0pdf.ampr.org http://db0wet.ampr.org http://db0ham.ampr.org http://44.143.10.90 http://web.oe2xzr.at.ampr.org http://dm0ha.ampr.org http://dm0zgw.ampr.org http://db0erf.ampr.org http://web.oe5xbl.at.ampr.org http://web.oe7xci.ampr.at http://44.168.12.11 http://server.db0anf.ampr.org http://www.db0fuz.ampr.org http://linux.db0zeh.ampr.org http://monitor.db0mhb.ampr.org http://db0bul.ampr.org http://rpt.db0pob.ampr.org http://db0kpg.ampr.org http://db0lip.ampr.org http://44.225.76.161 http://db0zdf-srv01.db0zdf.ampr.org http://raspberry.db0abz.ampr.org http://db0fc.ampr.org http://cloud.db0fc.ampr.org http://db0oha.ampr.org http://dk0mav.ampr.org /
Dean, I've just tried a traceroute from the cell at Paine, and it looks like it's connecting through ok. It's possible that something was funny with the IPIP tunnel, though I haven't changed anything there, so I'd guess it would be on the remote end. If it's continuing to not work for you, then something funny is going on. [nigel@Paine-s2] > /tool traceroute 44.225.56.72 # ADDRESS LOSS SENT LAST AVG BEST WORST STD-DEV STATUS 1 44.24.240.136 0% 70 0.3ms 0.4 0.3 1.7 0.2 2 44.24.242.7 0% 70 39.1ms 22.5 3 69.6 16.9 3 44.24.242.8 0% 70 84.6ms 68.9 36.5 183.1 28 44.24.242.4 4 44.130.60.100 0% 70 232.3ms 237.7 204.9 800.1 240 5 44.130.60.101 1.4% 70 221.3ms 236.5 203.1 342.3 234 6 44.224.2.5 0% 70 245ms 247.9 216.9 359.2 249.1 7 44.224.2.18 1.4% 70 266.5ms 252.6 218.2 575.3 240.4 8 44.224.53.158 0% 69 220.2ms 252.3 220.1 364.3 252.5 9 44.224.24.59 0% 69 247.4ms 263.9 231 390.8 252.7 10 44.225.56.72 0% 69 276.8ms 263.8 226 383.8 253 On Mar 28, 2014, at 8:08 AM, Dean Gibson AE7Q <hamwan@ae7q.net> wrote:
I currently can't connect to ANY in the list (someone else gave me as valid) below. Previously (about a week ago), I only tried a few in the list below, but those connected. A DNS lookup today on a few of them, returns an address in the 44 block, so I doubt it's DNS.
Here's a "traceroute" to 44.225.56.72 (in the list below):
traceroute to 44.225.56.72 (44.225.56.72), 30 hops max, 38 byte packets 1 5shpn-1_ext (192.168.3.251) 0.437 ms 0.255 ms 0.237 ms 2 44.24.240.161 (44.24.240.161) 56.927 ms 66.802 ms 10.479 ms 3 44.24.240.136 (44.24.240.136) 5.019 ms 26.476 ms 8.432 ms 4 44.24.242.7 (44.24.242.7) 37.010 ms 31.064 ms 8.447 ms 5 44.24.242.4 (44.24.242.4) 49.188 ms 64.406 ms 51.113 ms 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * *
On 2014-03-27 22:29, Nigel Vander Houwen wrote:
Can you give an example of something you were trying to access that's giving you issues?
Nigel K7NVH
On Mar 27, 2014, at 9:30 PM, Dean Gibson AE7Q <hamwan@ae7q.net> wrote:
Today I tried to access a number of 44.x.x.x/8 web sites that I was perfectly able to access a week ago, but cannot tonight. A "traceroute" shows that these accesses are leaving the 44.x.x.x/8 network and coming back in at UCSD. That of course could explain what is happening.
http://web.db0avh.ampr.org http://db0bi.ampr.org http://db0dah.ampr.org http://db0eeo.ampr.org http://db0end.ampr.org http://db0fhn.ampr.org http://db0res-svr.ampr.org http://db0gos.ampr.org http://db0dz.ampr.org http://db0ii.ampr.org http://db0iuz.ampr.org http://44.225.56.72/cms25 http://db0kwe.ampr.org http://srv.db0lj.ampr.org http://db0nis.ampr.org http://db0ovn.ampr.org http://44.225.60.2 http://db0sda.ampr.org http://db0ach.ampr.org http://db0pra.ampr.org http://websrv.db0pdf.ampr.org http://db0wet.ampr.org http://db0ham.ampr.org http://44.143.10.90 http://web.oe2xzr.at.ampr.org http://dm0ha.ampr.org http://dm0zgw.ampr.org http://db0erf.ampr.org http://web.oe5xbl.at.ampr.org http://web.oe7xci.ampr.at http://44.168.12.11 http://server.db0anf.ampr.org http://www.db0fuz.ampr.org http://linux.db0zeh.ampr.org http://monitor.db0mhb.ampr.org http://db0bul.ampr.org http://rpt.db0pob.ampr.org http://db0kpg.ampr.org http://db0lip.ampr.org http://44.225.76.161 http://db0zdf-srv01.db0zdf.ampr.org http://raspberry.db0abz.ampr.org http://db0fc.ampr.org http://cloud.db0fc.ampr.org http://db0oha.ampr.org http://dk0mav.ampr.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
What happens when you do a: "/ping 44.24.10.1" from the radio? I got that IP address from John Hays as a address that should respond to a ping from within the 44 block. All I get are timeouts. On 2014-03-28 08:49, Nigel Vander Houwen wrote:
Dean,
I've just tried a traceroute from the cell at Paine, and it looks like it's connecting through ok. It's possible that something was funny with the IPIP tunnel, though I haven't changed anything there, so I'd guess it would be on the remote end. If it's continuing to not work for you, then something funny is going on.
/[nigel@Paine-s2] > /tool traceroute 44.225.56.72 # ADDRESS LOSS SENT LAST AVG BEST WORST STD-DEV STATUS 1 44.24.240.136 0% 70 0.3ms 0.4 0.3 1.7 0.2 2 44.24.242.7 0% 70 39.1ms 22.5 3 69.6 16.9 3 44.24.242.8 0% 70 84.6ms 68.9 36.5 183.1 28 44.24.242.4 4 44.130.60.100 0% 70 232.3ms 237.7 204.9 800.1 240 5 44.130.60.101 1.4% 70 221.3ms 236.5 203.1 342.3 234 6 44.224.2.5 0% 70 245ms 247.9 216.9 359.2 249.1 7 44.224.2.18 1.4% 70 266.5ms 252.6 218.2 575.3 240.4 8 44.224.53.158 0% 69 220.2ms 252.3 220.1 364.3 252.5 9 44.224.24.59 0% 69 247.4ms 263.9 231 390.8 252.7 10 44.225.56.72 0% 69 276.8ms 263.8 226 383.8 253 / On Mar 28, 2014, at 8:08 AM, Dean Gibson AE7Q <hamwan@ae7q.net> wrote:
I currently can't connect to ANY in the list (someone else gave me as valid) below. Previously (about a week ago), I only tried a few in the list below, but those connected. A DNS lookup today on a few of them, returns an address in the 44 block, so I doubt it's DNS.
Here's a "traceroute" to 44.225.56.72 (in the list below):
/traceroute to 44.225.56.72 (44.225.56.72), 30 hops max, 38 byte packets 1 5shpn-1_ext (192.168.3.251) 0.437 ms 0.255 ms 0.237 ms 2 44.24.240.161 (44.24.240.161) 56.927 ms 66.802 ms 10.479 ms 3 44.24.240.136 (44.24.240.136) 5.019 ms 26.476 ms 8.432 ms 4 44.24.242.7 (44.24.242.7) 37.010 ms 31.064 ms 8.447 ms 5 44.24.242.4 (44.24.242.4) 49.188 ms 64.406 ms 51.113 ms 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * /
On 2014-03-27 22:29, Nigel Vander Houwen wrote:
Can you give an example of something you were trying to access that's giving you issues?
Nigel K7NVH
On Mar 27, 2014, at 9:30 PM, Dean Gibson AE7Q <hamwan@ae7q.net> wrote:
Today I tried to access a number of 44.x.x.x/8 web sites that I was perfectly able to access a week ago, but cannot tonight. A "traceroute" shows that these accesses are leaving the 44.x.x.x/8 network and coming back in at UCSD. That of course could explain what is happening.
/http://web.db0avh.ampr.org http://db0bi.ampr.org http://db0dah.ampr.org http://db0eeo.ampr.org http://db0end.ampr.org http://db0fhn.ampr.org http://db0res-svr.ampr.org http://db0gos.ampr.org http://db0dz.ampr.org http://db0ii.ampr.org http://db0iuz.ampr.org http://44.225.56.72/cms25 http://db0kwe.ampr.org http://srv.db0lj.ampr.org http://db0nis.ampr.org http://db0ovn.ampr.org http://44.225.60.2 http://db0sda.ampr.org http://db0ach.ampr.org http://db0pra.ampr.org http://websrv.db0pdf.ampr.org http://db0wet.ampr.org http://db0ham.ampr.org http://44.143.10.90 http://web.oe2xzr.at.ampr.org http://dm0ha.ampr.org http://dm0zgw.ampr.org http://db0erf.ampr.org http://web.oe5xbl.at.ampr.org http://web.oe7xci.ampr.at http://44.168.12.11 http://server.db0anf.ampr.org http://www.db0fuz.ampr.org http://linux.db0zeh.ampr.org http://monitor.db0mhb.ampr.org http://db0bul.ampr.org http://rpt.db0pob.ampr.org http://db0kpg.ampr.org http://db0lip.ampr.org http://44.225.76.161 http://db0zdf-srv01.db0zdf.ampr.org http://raspberry.db0abz.ampr.org http://db0fc.ampr.org http://cloud.db0fc.ampr.org http://db0oha.ampr.org http://dk0mav.ampr.org /
Ping may be blocked ... that address is on IPIP tunnel. ------------------------------ John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223 <http://k7ve.org/blog> <http://twitter.com/#!/john_hays> <http://www.facebook.com/john.d.hays> On Fri, Mar 28, 2014 at 12:48 PM, Dean Gibson AE7Q <hamwan@ae7q.net> wrote:
What happens when you do a: "/ping 44.24.10.1" from the radio? I got that IP address from John Hays as a address that should respond to a ping from within the 44 block. All I get are timeouts.
On 2014-03-28 08:49, Nigel Vander Houwen wrote:
Dean,
I've just tried a traceroute from the cell at Paine, and it looks like it's connecting through ok. It's possible that something was funny with the IPIP tunnel, though I haven't changed anything there, so I'd guess it would be on the remote end. If it's continuing to not work for you, then something funny is going on. *[nigel@Paine-s2] > /tool traceroute 44.225.56.72 # ADDRESS LOSS SENT LAST AVG BEST WORST STD-DEV STATUS 1 44.24.240.136 <1%2044.24.240.136> 0% 70 0.3ms 0.4 0.3 1.7 0.2 2 44.24.242.7 0% 70 39.1ms 22.5 3 69.6 16.9 3 44.24.242.8 0% 70 84.6ms 68.9 36.5 183.1 28 44.24.242.4 4 44.130.60.100 0% 70 232.3ms 237.7 204.9 800.1 240 5 44.130.60.101 1.4% 70 221.3ms 236.5 203.1 342.3 234 6 44.224.2.5 0% 70 245ms 247.9 216.9 359.2 249.1 7 44.224.2.18 1.4% 70 266.5ms 252.6 218.2 575.3 240.4 8 44.224.53.158 0% 69 220.2ms 252.3 220.1 364.3 252.5 9 44.224.24.59 0% 69 247.4ms 263.9 231 390.8 252.7 10 44.225.56.72 0% 69 276.8ms 263.8 226 383.8 253 * On Mar 28, 2014, at 8:08 AM, Dean Gibson AE7Q <hamwan@ae7q.net> <hamwan@ae7q.net> wrote:
I currently can't connect to ANY in the list (someone else gave me as valid) below. Previously (about a week ago), I only tried a few in the list below, but those connected. A DNS lookup today on a few of them, returns an address in the 44 block, so I doubt it's DNS.
Here's a "traceroute" to 44.225.56.72 (in the list below): *traceroute to 44.225.56.72 (44.225.56.72), 30 hops max, 38 byte packets 1 5shpn-1_ext (192.168.3.251) 0.437 ms 0.255 ms 0.237 ms 2 44.24.240.161 (44.24.240.161) 56.927 ms 66.802 ms 10.479 ms 3 44.24.240.136 (44.24.240.136) 5.019 ms 26.476 ms 8.432 ms 4 44.24.242.7 (44.24.242.7) 37.010 ms 31.064 ms 8.447 ms 5 44.24.242.4 (44.24.242.4) 49.188 ms 64.406 ms 51.113 ms 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * *
On 2014-03-27 22:29, Nigel Vander Houwen wrote:
Can you give an example of something you were trying to access that's giving you issues?
Nigel K7NVH
On Mar 27, 2014, at 9:30 PM, Dean Gibson AE7Q <hamwan@ae7q.net> <hamwan@ae7q.net> wrote:
Today I tried to access a number of 44.x.x.x/8 web sites that I was perfectly able to access a week ago, but cannot tonight. A "traceroute" shows that these accesses are leaving the 44.x.x.x/8 network and coming back in at UCSD. That of course could explain what is happening.
*http://web.db0avh.ampr.org <http://web.db0avh.ampr.org> http://db0bi.ampr.org <http://db0bi.ampr.org> http://db0dah.ampr.org <http://db0dah.ampr.org> http://db0eeo.ampr.org <http://db0eeo.ampr.org> http://db0end.ampr.org <http://db0end.ampr.org> http://db0fhn.ampr.org <http://db0fhn.ampr.org> http://db0res-svr.ampr.org <http://db0res-svr.ampr.org> http://db0gos.ampr.org <http://db0gos.ampr.org> http://db0dz.ampr.org <http://db0dz.ampr.org> http://db0ii.ampr.org <http://db0ii.ampr.org> http://db0iuz.ampr.org <http://db0iuz.ampr.org> http://44.225.56.72/cms25 <http://44.225.56.72/cms25> http://db0kwe.ampr.org <http://db0kwe.ampr.org> http://srv.db0lj.ampr.org <http://srv.db0lj.ampr.org> http://db0nis.ampr.org <http://db0nis.ampr.org> http://db0ovn.ampr.org <http://db0ovn.ampr.org> http://44.225.60.2 <http://44.225.60.2> http://db0sda.ampr.org <http://db0sda.ampr.org> http://db0ach.ampr.org <http://db0ach.ampr.org> http://db0pra.ampr.org <http://db0pra.ampr.org> http://websrv.db0pdf.ampr.org <http://websrv.db0pdf.ampr.org> http://db0wet.ampr.org <http://db0wet.ampr.org> http://db0ham.ampr.org <http://db0ham.ampr.org> http://44.143.10.90 <http://44.143.10.90> http://web.oe2xzr.at.ampr.org <http://web.oe2xzr.at.ampr.org> http://dm0ha.ampr.org <http://dm0ha.ampr.org> http://dm0zgw.ampr.org <http://dm0zgw.ampr.org> http://db0erf.ampr.org <http://db0erf.ampr.org> http://web.oe5xbl.at.ampr.org <http://web.oe5xbl.at.ampr.org> http://web.oe7xci.ampr.at <http://web.oe7xci.ampr.at> http://44.168.12.11 <http://44.168.12.11> http://server.db0anf.ampr.org <http://server.db0anf.ampr.org> http://www.db0fuz.ampr.org <http://www.db0fuz.ampr.org> http://linux.db0zeh.ampr.org <http://linux.db0zeh.ampr.org> http://monitor.db0mhb.ampr.org <http://monitor.db0mhb.ampr.org> http://db0bul.ampr.org <http://db0bul.ampr.org> http://rpt.db0pob.ampr.org <http://rpt.db0pob.ampr.org> http://db0kpg.ampr.org <http://db0kpg.ampr.org> http://db0lip.ampr.org <http://db0lip.ampr.org> http://44.225.76.161 <http://44.225.76.161> http://db0zdf-srv01.db0zdf.ampr.org <http://db0zdf-srv01.db0zdf.ampr.org> http://raspberry.db0abz.ampr.org <http://raspberry.db0abz.ampr.org> http://db0fc.ampr.org <http://db0fc.ampr.org> http://cloud.db0fc.ampr.org <http://cloud.db0fc.ampr.org> http://db0oha.ampr.org <http://db0oha.ampr.org> http://dk0mav.ampr.org <http://dk0mav.ampr.org> *
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
OK, does anyone have a 44.x.x.x IP address OUTSIDE the 44.24.240.0/20 block, that should respond to a "/ping ..." ??? Why should my traceroute be different than the one from Paine??? //tool traceroute 44.225.56.72 # ADDRESS LOSS SENT LAST AVG BEST WORST STD-DEV STATUS 1 44.24.240.161 0% 37 39.8ms 57.7 6.9 151.6 36.5 2 44.24.240.136 0% 37 8.4ms 12.4 3.7 44.3 11 3 44.24.242.7 0% 37 15.1ms 24.3 8.4 63.8 14 4 44.24.242.4 0% 37 111.1ms 72.8 41.4 204.3 35.1 44.24.242.8 5 100% 37 timeout 6 100% 37 timeout 7 100% 37 timeout 8 100% 36 timeout 9 100% 36 timeout/ ??? -- Dean On 2014-03-28 13:09, John D. Hays wrote:
Ping may be blocked ... that address is on IPIP tunnel.
------------------------------------------------------------------------ John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223 <http://k7ve.org/blog> <http://twitter.com/#%21/john_hays> <http://www.facebook.com/john.d.hays>
On Fri, Mar 28, 2014 at 12:48 PM, Dean Gibson AE7Q <hamwan@ae7q.net <mailto:hamwan@ae7q.net>> wrote:
What happens when you do a: "/ping 44.24.10.1" from the radio? I got that IP address from John Hays as a address that should respond to a ping from within the 44 block. All I get are timeouts.
On 2014-03-28 08:49, Nigel Vander Houwen wrote:
Dean,
I've just tried a traceroute from the cell at Paine, and it looks like it's connecting through ok. It's possible that something was funny with the IPIP tunnel, though I haven't changed anything there, so I'd guess it would be on the remote end. If it's continuing to not work for you, then something funny is going on.
/[nigel@Paine-s2] > /tool traceroute 44.225.56.72 # ADDRESS LOSS SENT LAST AVG BEST WORST STD-DEV STATUS 1 44.24.240.136 <tel:1%2044.24.240.136> 0% 70 0.3ms 0.4 0.3 1.7 0.2 2 44.24.242.7 0% 70 39.1ms 22.5 3 69.6 16.9 3 44.24.242.8 0% 70 84.6ms 68.9 36.5 183.1 28 44.24.242.4 4 44.130.60.100 0% 70 232.3ms 237.7 204.9 800.1 240 5 44.130.60.101 1.4% 70 221.3ms 236.5 203.1 342.3 234 6 44.224.2.5 0% 70 245ms 247.9 216.9 359.2 249.1 7 44.224.2.18 1.4% 70 266.5ms 252.6 218.2 575.3 240.4 8 44.224.53.158 0% 69 220.2ms 252.3 220.1 364.3 252.5 9 44.224.24.59 0% 69 247.4ms 263.9 231 390.8 252.7 10 44.225.56.72 0% 69 276.8ms 263.8 226 383.8 253 / On Mar 28, 2014, at 8:08 AM, Dean Gibson AE7Q<hamwan@ae7q.net> <mailto:hamwan@ae7q.net> wrote:
I currently can't connect to ANY in the list (someone else gave me as valid) below. Previously (about a week ago), I only tried a few in the list below, but those connected. A DNS lookup today on a few of them, returns an address in the 44 block, so I doubt it's DNS.
Here's a "traceroute" to 44.225.56.72 (in the list below):
/traceroute to 44.225.56.72 (44.225.56.72), 30 hops max, 38 byte packets 1 5shpn-1_ext (192.168.3.251) 0.437 ms 0.255 ms 0.237 ms 2 44.24.240.161 (44.24.240.161) 56.927 ms 66.802 ms 10.479 ms 3 44.24.240.136 (44.24.240.136) 5.019 ms 26.476 ms 8.432 ms 4 44.24.242.7 (44.24.242.7) 37.010 ms 31.064 ms 8.447 ms 5 44.24.242.4 (44.24.242.4) 49.188 ms 64.406 ms 51.113 ms 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * /
On 2014-03-27 22:29, Nigel Vander Houwen wrote:
Can you give an example of something you were trying to access that's giving you issues?
Nigel K7NVH
On Mar 27, 2014, at 9:30 PM, Dean Gibson AE7Q <hamwan@ae7q.net> <mailto:hamwan@ae7q.net> wrote:
Today I tried to access a number of 44.x.x.x/8 web sites that I was perfectly able to access a week ago, but cannot tonight. A "traceroute" shows that these accesses are leaving the 44.x.x.x/8 network and coming back in at UCSD. That of course could explain what is happening.
/http://web.db0avh.ampr.org http://db0bi.ampr.org http://db0dah.ampr.org http://db0eeo.ampr.org http://db0end.ampr.org http://db0fhn.ampr.org http://db0res-svr.ampr.org http://db0gos.ampr.org http://db0dz.ampr.org http://db0ii.ampr.org http://db0iuz.ampr.org http://44.225.56.72/cms25 http://db0kwe.ampr.org http://srv.db0lj.ampr.org http://db0nis.ampr.org http://db0ovn.ampr.org http://44.225.60.2 http://db0sda.ampr.org http://db0ach.ampr.org http://db0pra.ampr.org http://websrv.db0pdf.ampr.org http://db0wet.ampr.org http://db0ham.ampr.org http://44.143.10.90 http://web.oe2xzr.at.ampr.org http://dm0ha.ampr.org http://dm0zgw.ampr.org http://db0erf.ampr.org http://web.oe5xbl.at.ampr.org http://web.oe7xci.ampr.at http://44.168.12.11 http://server.db0anf.ampr.org http://www.db0fuz.ampr.org http://linux.db0zeh.ampr.org http://monitor.db0mhb.ampr.org http://db0bul.ampr.org http://rpt.db0pob.ampr.org http://db0kpg.ampr.org http://db0lip.ampr.org http://44.225.76.161 http://db0zdf-srv01.db0zdf.ampr.org http://raspberry.db0abz.ampr.org http://db0fc.ampr.org http://cloud.db0fc.ampr.org http://db0oha.ampr.org http://dk0mav.ampr.org /
_______________________________________________ PSDR mailing list PSDR@hamwan.org <mailto:PSDR@hamwan.org> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
No it's not (blocked). After Tom's changes, I can ping it from my 44.x.x.x address just fine. On 2014-03-28 13:09, John D. Hays wrote:
Ping may be blocked ... that address is on IPIP tunnel.
------------------------------------------------------------------------ John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223 <http://k7ve.org/blog> <http://twitter.com/#%21/john_hays> <http://www.facebook.com/john.d.hays>
On Fri, Mar 28, 2014 at 12:48 PM, Dean Gibson AE7Q <hamwan@ae7q.net <mailto:hamwan@ae7q.net>> wrote:
What happens when you do a: "/ping 44.24.10.1" from the radio? I got that IP address from John Hays as a address that should respond to a ping from within the 44 block. All I get are timeouts.
On Fri, Mar 28, 2014 at 12:48 PM, Dean Gibson AE7Q <hamwan@ae7q.net> wrote:
What happens when you do a: "/ping 44.24.10.1" from the radio? I got that IP address from John Hays as a address that should respond to a ping from within the 44 block. All I get are timeouts.
Dean, HamWAN is a multi-homed (redundant) network. We have multiple origination points for the 44.24.240.0/20 IP block. However, AMPR (at least the AMPR portal) only allows one endpoint per network. The endpoint we currently have configured with AMPR is 209.189.196.68, our Seattle router. It looks like from parts of the network it's trying to route 44.24.10.0/24 out HamWAN's Corvallis router (198.178.136.80), but John Hays system is not listening for IPIP packets from 198.178.136.80. This is reasonable, considering we're not advertising that address through AMPR. The problem is AMPR won't let us advertise it. We might be able to solve this by removing the redundancy within HamWAN. I'm going to send another message to the 44net mailing list to see why they have it programmed not to let us have redundant endpoints. Tom KD7LXL
On 2014-03-28 13:36, Tom Hayward wrote:
On Fri, Mar 28, 2014 at 12:48 PM, Dean Gibson AE7Q <hamwan@ae7q.net> wrote:
What happens when you do a: "/ping 44.24.10.1" from the radio? I got that IP address from John Hays as a address that should respond to a ping from within the 44 block. All I get are timeouts. Dean,
HamWAN is a multi-homed (redundant) network. We have multiple origination points for the 44.24.240.0/20 IP block. However, AMPR (at least the AMPR portal) only allows one endpoint per network. The endpoint we currently have configured with AMPR is 209.189.196.68, our Seattle router.
It looks like from parts of the network it's trying to route 44.24.10.0/24 out HamWAN's Corvallis router (198.178.136.80), but John Hays system is not listening for IPIP packets from 198.178.136.80. This is reasonable, considering we're not advertising that address through AMPR. The problem is AMPR won't let us advertise it.
We might be able to solve this by removing the redundancy within HamWAN. I'm going to send another message to the 44net mailing list to see why they have it programmed not to let us have redundant endpoints.
Tom KD7LXL
Does that also explain part of why I can't access any of the HTTP sites in my prior list, but I could a week ago? Ie, there's a bit of randomness in the redundancy selection of an origination point?
On Fri, Mar 28, 2014 at 1:49 PM, Dean Gibson AE7Q <hamwan@ae7q.net> wrote:
Does that also explain part of why I can't access any of the HTTP sites in my prior list, but I could a week ago? Ie, there's a bit of randomness in the redundancy selection of an origination point?
If they were 44net HTTP sites, then yes, this could explain it. The AMPR routes have been removed from HamWAN's Corvallis router for now, meaning they'll all go through the Seattle router. This should fix routing for you. Unfortunately it leaves HamWAN with a single point of failure (or a single point of success, considering AMPR has never supported redundancy in the first place). Tom KD7LXL
On 2014-03-28 14:06, Tom Hayward wrote:
On Fri, Mar 28, 2014 at 1:49 PM, Dean Gibson AE7Q <hamwan@ae7q.net> wrote:
Does that also explain part of why I can't access any of the HTTP sites in my prior list, but I could a week ago? Ie, there's a bit of randomness in the redundancy selection of an origination point? If they were 44net HTTP sites, then yes, this could explain it.
The AMPR routes have been removed from HamWAN's Corvallis router for now, meaning they'll all go through the Seattle router. This should fix routing for you. Unfortunately it leaves HamWAN with a single point of failure (or a single point of success, considering AMPR has never supported redundancy in the first place).
Tom KD7LXL
Yes, I can access all my "problem" sites now. If I understand what you are saying, the current configuration: 1. Has a single point of failure for access to 44net addresses. 2. Has multiple routes (ie, redundancy) to the rest of the Internet. Or is that possible? That would seem like the best (current) configuration. -- Dean ps: Moving my antenna 8 ft to the east gives a 9dBm increase in signal-strength. Pictures pending (eg, when the rain stops). pps: While setting up the antenna, I received a hand-delivered "stop work order" from my homeowner's association. A quick phone call and two words ("federal preemption") fixed that. Details with the pictures to follow ...
On Fri, Mar 28, 2014 at 3:36 PM, Dean Gibson AE7Q <hamwan@ae7q.net> wrote:
Yes, I can access all my "problem" sites now. If I understand what you are saying, the current configuration:
Has a single point of failure for access to 44net addresses. Has multiple routes (ie, redundancy) to the rest of the Internet.
Yes, this is precisely correct.
-- Dean
ps: Moving my antenna 8 ft to the east gives a 9dBm increase in signal-strength. Pictures pending (eg, when the rain stops).
Excellent! Nigel had the same experience on his roof. Something for everyone to be aware of.
pps: While setting up the antenna, I received a hand-delivered "stop work order" from my homeowner's association. A quick phone call and two words ("federal preemption") fixed that. Details with the pictures to follow ...
Ha! I'm glad they accepted your excuse. I still maintain that I won't move into a neighborhood with a homeowners association. We'll see how that goes. Tom KD7LXL
On 2014-03-28 15:40, Tom Hayward wrote:
On Fri, Mar 28, 2014 at 3:36 PM, Dean Gibson AE7Q <hamwan@ae7q.net> wrote:
pps: While setting up the antenna, I received a hand-delivered "stop work order" from my homeowner's association. A quick phone call and two words ("federal preemption") fixed that. Details with the pictures to follow ... Ha! I'm glad they accepted your excuse. I still maintain that I won't move into a neighborhood with a homeowners association. We'll see how that goes.
Tom KD7LXL
Well, being one of the largest homeowners associations in the state (they used to be the largest) they were very familiar with the FCC rules. They've had their lawyer look into all sorts of antenna issues, and have come to the conclusion that they'd lose most cases in court. Apparently someone had reported the antenna as much larger than it is. Part of the conversation went like this: HOA: Is the antenna over a meter? Me: No, it's nowhere close to a meter. HOA: We can't allow it if it's over a meter. Me: Over a meter? HOA: Yes, the FCC says we can prohibit it, if it's over a meter. Something like 42 inches. Me: Oh, you mean SIZE. 39.37 inches. No, it's under a meter. HOA: Thank you. There's no need for you to apply for an Architectural Change Request. I did request that a member of the Architectural Control Committee review what I had done for appearance, as I have not desire to annoy my neighbors unnecessarily. A woman from the Committee came by the next morning (this is one of the advantages of a big HOA with staff: things don't get delayed) who was familiar with the construction trade, and she said that she thought I'd done the best reasonable job with the appearance.
participants (7)
-
Bart Kus -
Dan Ransom, PE -
Daniel Ransom
-
Dean Gibson AE7Q -
John D. Hays -
Nigel Vander Houwen -
Tom Hayward