44net

44net@mailman.ampr.org

3198 discussions

URONode on Summer 2014 issue of TAPR PSR
by Dimitrios Valaris 09 Aug '14

09 Aug '14

Hi all, I just received the "Summer 2014 issue of TAPR PSR" and saw a nice article about UROnode in page 5. Congrats to Brian N1URO. It is the best NODE software I have ever used. --- 73 de Demetre - SV1UY e-mail: demetre.sv1uy(a)gmail.com Radio e-mail: sv1uy(a)winlink.org AMPRnet e-mail: sv1uy(a)sv1uy.ampr.org PACKET mail: SV1UY(a)SV1UY.ATH.GRC.EU WEB: http://www.qsl.net/sv1uy

2 4

testing for source address filtering....
by Eric Fort 08 Aug '14

08 Aug '14

Occasionally I have access to 2 Verizon DSL connections in the same location. the connections while being the same provider are generally a dynamic IP from different /24 subnets and there's about 4 hops between them. (once they reach a common point a couple hops away all other traceroute data is the same. how can I test to see if one connection filters source addresses belonging to the other? (and any guesses as to what the results may be?) Eric

2 1

Re: [44net] 44Net Digest, Vol 3, Issue 128
by Ernest.Tse＠Pacswitch 08 Aug '14

08 Aug '14

An embedded and charset-unspecified text was scrubbed... Name: not available URL: <http://hamradio.ucsd.edu/mailman/private/44net/attachments/20140808/2f26caa…>

1 0

Re: [44net] Performance of DNS
by Rob Janssen 07 Aug '14

07 Aug '14

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > Re: [44net] Performance of DNS > From: > David Ranch <amprgw(a)trinnet.net> > Date: > 08/07/2014 03:04 AM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > > Beyond filtering, are you looking at your named logs too? There are a ton of old / misconfigured DNS servers out there that don't support EDNS: > > success resolving 'blns71.spamcop.net/A' (in 'spamcop.net'?) after disabling EDNS success resolving 'bcwww.enet.cu/A' (in 'enet.cu'?) after reducing the advertised EDNS UDP packet size to 512 octets > > success resolving 'hispructs.com/A' (in 'hispructs.com'?) after reducing the advertised EDNS UDP packet size to 512 octets I recognize that problem but it is not occurring on this server. Probably the ampr.org nameservers are not affected by that, and the machine does not make many other queries. The only recurring error messages are about IPv6 DNS server addresses being unreachable, but only one or two a day. I have now started it with -4 option but it will probably not change much. Also disabled dnssec. Let's see... Rob

1 0

Re: [44net] Performance of DNS
by Rob Janssen 07 Aug '14

07 Aug '14

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > Re: [44net] Performance of DNS > From: > Jeroen Massar <jeroen(a)massar.ch> > Date: > 08/06/2014 11:22 AM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > Jeroen, In general: please read the entire mail before starting to comment on individual paragraphs, so you don't need to ask questions that are answered a few paragraphs down the same mail. The system is running Debian Wheezy, all uptodate, with bind9 version 9.8.4 plus Debian patches. It is not available to the outside no so security worries. What I see is that it does not cache ampr.org addresses very long, but that does not surprise me because the default TTL in the zone is only one hour. Of course everything would perform better when the TTL was the more usual 24hours, but undoubtedly there was a good reason to set this TTL. (lately it was useful for me as I changed the external address of the machine and the update was propagated quickly in DNS, but in general I would think the zone is very static) What I am surprised about is that the measured relative performance of the 7 alternative DNS servers is apparently not kept by bind long enough to be useful. The TTL at that level is 24 hours but I think I have often seen that when doing the same lookups within 24 hours I see lookup delays again. The statistics command you gave does not provide that info, I wonder if there is some bind command to query its measured timers and preferred servers. We have several timeservers on net-44 addresses and I do "ntpq -p -c rv -c mrulist" a couple of times a day now that we are testing and deploying. It was slow every time, of course the cached lookups are gone because the previous try was more than an hour ago, but apparently the DNS preference info was gone too and queries were again sent to slow (for me) servers. After my experimental change with the hardwired forwarders everything works much better. I'm not sure I want to keep it, but it certainly indicates that there *is* a way in which bind could handle it more efficiently. Maybe I am missing some setting, I have experimented with setting a forwarder (and forward first) at top level as well. Probably I should turn off the DNSSEC that has been enabled by default by bind and Debian, that appears to cause a lot of extra overhead too. Rob

3 2

New services idea.
by kb9mwr＠gmail.com 07 Aug '14

07 Aug '14

First, Lynwood thanks for sharing PHP code snippet. Does anyone know much about google maps? More than 15 years ago a younger local ham friend of mine wrote some web based interactive tools for wireless link planning. Maybe you have run into them: http://n9zia.ampr.org/ This isn't presently on 44-net. I have just been using the ampr dns to give it a hostname that has been pointing to my home cable modem for a long time now. They run horribly slow (same computer for 15 years and slow upload speed) I'd love to see these tools freshened up a bit to use PHP, and possibly integrate google maps. Neither the original author, Joe N9ZIA or myself really have a lot of experience with either. But we are both surprised someone hasn't already done this. Just throwing the idea out there for anyone who would like a project, the code is open under GPL. The tools help promote modern RF network planning. After a rewrite perhaps they could be hosted on a 44 IP, and put a paypal please donate nag screen if you come in from a commercial IP. The paypal proceeds can go to helping ARDC with Brian's ok. Steve, KB9MWR

3 3

Re: [44net] Performance of DNS
by Rob Janssen 06 Aug '14

06 Aug '14

More tracing reveals why the times are sometimes as high as I reported... It first got my attention because commands like "netstat -t" and "ntpq -p" took quite some time to execute when 44.x.x.x addresses were in the listing, stopping for each reverse lookup. I had also noticed that "ping callsign.ampr.org" always takes some time before it sends the first ping. So I decided to investigate. I used this command to time it: time host callsign.ampr.org It appears that when the callsign exists, this does two lookups, for the A and MX record. When the callsign does not exist (I also tested that), it also does two lookups: the specified one, and the one with .ampr.org appended a second time. This is caused by "search ampr.org" in /etc/resolv.conf. It was put there by the Linux installer, I know many Linux distributors do that. (you specifiy a hostname and domainname during install, and it will put the domainname in /etc/resolv.conf as a search line) That explains the long execution time of "host" that could not be explained by a single lookup. I think it is not very clever of the resolver library to append a search domain that already was in the query, but maybe there are some cases where this is useful? Anyway, I removed that from resolv.conf as this machine is not for end-users anyway, and I don't mind typing full domain names. It doubles the speed of all lookups of nonexisting names, and reduces the load on the ampr.org nameservers as well. This doubles the speed of the host command, but of course the reverse lookups are not affected. When using those two local DNS servers first, they are fast. Bind should learn and remember that, I think. It is only good that ampr.org DNS servers are around the globe, and a pity that bind does not take that to an advantage. It does do that for forwarders, at least that is written in the docs. (this machine runs bind as a caching resolver and the nameserver in resolv.conf is 127.0.0.1) Rob

3 2

Re: [44net] Performance of DNS
by Rob Janssen 05 Aug '14

05 Aug '14

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > Re: [44net] Performance of DNS > From: > Brian Kantor <Brian(a)UCSD.Edu> > Date: > 08/05/2014 07:21 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > On Tue, Aug 05, 2014 at 07:14:12PM +0200, Rob Janssen wrote: >> >I often experience relatively slow lookups of DNS records in .ampr.org and 44.in-addr.arpa. > It can be instructive to use the 'dig' '+trace' option to do lookups > as that will give you timing results as the query descends the tree. > That way you can get an idea of where the delay may be. Together with > the '@' option to direct your query to a particular nameserver you might > be able to identify the bottleneck when it occurs. > - Brian > I did some testing and I find that the two servers closest to me (in DE and UK) return results very quickly, under 80ms, while munnari.OZ.AU is very slow, it takes a second per query. Of course it is on the other end of the world, the pingtime is 350ms. The lookup of org and ampr (when not in cache) also take 300ms each, so in total a lookup takes quite some time. When I trick the whole thing using these bind9 zones in my local caching resolver: zone "ampr.org" IN { type forward; forward first; forwarders { 192.109.42.4; 195.66.148.101; }; }; zone "44.in-addr.arpa" IN { type forward; forward first; forwarders { 192.109.42.4; 195.66.148.101; }; }; everything is very very fast. of course this is to be expected, as the tree lookups are no longer required and the fastest (for me) servers are used first. But of course it is a dirty trick, and it will fail when those servers change address. It looks like bind does not remember performance of DNS servers as it does for forwarders, or when it does it may have forgotten that info by the time it is required again and therefore does not use only the fastest servers? Rob

1 0

seeking recommendations for VPN capible (home) router
by Eric Fort 05 Aug '14

05 Aug '14

I'm presently seeking recommendations for a consumer grade home router that will work as both a vpn client and vpn server for PPTP, L2TP, OpenVPN, and IPSEC protocols. support for plain GRE would be useful as well. the router should be easy to configure with a fill in the boxes and check marks type web interface. Ideally an unlimited number of VPN tunnels would be supported along with support for RIP and OSPF. what does this list know of that comes at least close to this? Eric AF6EP

5 4

Performance of DNS
by Rob Janssen 05 Aug '14

05 Aug '14

I often experience relatively slow lookups of DNS records in .ampr.org and 44.in-addr.arpa. Not every time, but lookup times of 2-3 seconds occur quite often, especially for the first one in a series (the TTL in the zones is only an hour, so there is little caching). 44.in-addr.arpa also sometimes fail for existing hosts, to succeed when they are re-tried later. Do other people see this? It looks like there are 7 DNS servers, which seems to be plenty. Are they overloaded? Do we need or like to have more DNS servers? Should I volunteer to provide one? Or could there be another reason for this phenomenon? Rob

3 2

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net