Turns out you have to specify the interface address for sendmail to
respond to, 127.0.0.1 is default so that is why that always worked. I
never ran into that one before,
That explains this weirdness.. Two boxes on my local LAN with no
iptables software firewalls or hardware firewalls between them, and
selinux off on both:
[root@kb9mwr ~]# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:21:85:9C:60:42
inet addr:192.168.1.100 Bcast:192.168.255.255 Mask:255.255.0.0
inet6 addr: fe80::221:85ff:fe9c:6042/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:5421757 errors:0 dropped:0 overruns:0 frame:0
TX packets:4042659 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1012253009 (965.3 MiB) TX bytes:2506193160 (2.3 GiB)
Interrupt:58 Base address:0xe000
[root@kb9mwr ~]# telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
220 kb9mwr.host.org ESMTP Sendmail 8.13.8/8.13.8; Mon, 11 Aug 2014
19:59:42 -0500
^]
telnet>
root@pbx:~ $ telnet 192.168.1.100 25
Trying 192.168.1.100...
telnet: connect to address 192.168.1.100: Connection refused
telnet: Unable to connect to remote host: Connection refused
I was well aware that most ISP's block that port but was really
stumped as to why to PC's on the same network could not talk to each
other on that port yet could on all other ports.
You learn something new every day.
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
