Is anyone running a SMTP server on their gateway?
Most ISP's block port 25 outgoing, the problem I am seeing.
I see a email handshake come in and forward over the wireless LAN, But
when it comes from a non 44 IP is tries to reply using my assigned ISP
provided IP and obviously that doesn't work.
So is there some way with IP tables or something else to set and
advanced IP rule where is it's a destination on port 25 to route thru
amprgw.sysnet.ucsd.edu using my 44 address?
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
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
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
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
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
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
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
