9 Jun
2017
9 Jun
'17
6:29 a.m.
Lynwood,
It appears that your dynamic address gateway 'www.kb3vwg.info'
keeps cycling between address 173.66.138.32 and 71.178.210.39.
When it resolves to the latter address, your 44net hosts are
reachable. It did so this morning whilst I happened to be looking:
Jun 9 03:15:05 <local0.info> amprgw ipipd[51724]: route changed [137]:
44.60.44.0/24: from 173.66.138.32 to 71.178.210.39
and I was able to connect to your web server on 44.60.44.10.
I don't know why this is happening. Is your commercial IP really changing
as often as it appears from the logs or is this a problem at your dynamic
address provider?
- Brian
Jun 8 07:13:43 <local0.info> amprgw ipipd[51724]: route changed [129]:
44.60.44.0/24: from 173.66.138.32 to 71.178.210.39
Jun 8 07:18:02 <local0.info> amprgw ipipd[51724]: route changed [138]:
44.60.44.0/24: from 71.178.210.39 to 173.66.138.32
Jun 8 08:04:37 <local0.info> amprgw ipipd[51724]: route changed [138]:
44.60.44.0/24: from 173.66.138.32 to 71.178.210.39
Jun 8 08:15:05 <local0.info> amprgw ipipd[51724]: route changed [138]:
44.60.44.0/24: from 71.178.210.39 to 173.66.138.32
Jun 8 09:15:05 <local0.info> amprgw ipipd[51724]: route changed [138]:
44.60.44.0/24: from 173.66.138.32 to 71.178.210.39
Jun 8 15:15:05 <local0.info> amprgw ipipd[51724]: route changed [137]:
44.60.44.0/24: from 71.178.210.39 to 173.66.138.32
Jun 8 16:15:05 <local0.info> amprgw ipipd[51724]: route changed [137]:
44.60.44.0/24: from 173.66.138.32 to 71.178.210.39
Jun 8 19:15:05 <local0.info> amprgw ipipd[51724]: route changed [137]:
44.60.44.0/24: from 71.178.210.39 to 173.66.138.32
Jun 8 22:15:05 <local0.info> amprgw ipipd[51724]: route changed [137]:
44.60.44.0/24: from 173.66.138.32 to 71.178.210.39
9 Jun
9 Jun
1:54 p.m.
Brian,
As I noted yesterday:
On 06/08/2017 09:47 AM, lleachii(a)aol.com wrote:
On my side, the IP changed around 18:00 UTC on
Tuesday, June 6th.
Then, my IP changed to 71.178.210.39.
*
**It NEVER switched back. Something's wrong... *
lleach@lleach:~$ nslookup www.kb3vwg.info
Server: 127.0.1.1
Address: 127.0.1.1#53
Non-authoritative answer:
Name: www.kb3vwg.info
Address: 71.178.210.39
lleach@lleach:~$ nslookup
Could there be a reason the portal keep reverting to the stale data??
Again, to be clear, my IP has not reverted; and no DDNS software is
reporting the old IP.
- Lynwood
KB3VWG
server ns1.he.net
Default server:
ns1.he.net
Address: 216.218.130.2#53
Default server: ns1.he.net
Address: 2001:470:100::2#53
Server: ns1.he.net
Address: 216.218.130.2#53
Name: www.kb3vwg.info
Address: 71.178.210.39 I don't know why this is happening. Is your
commercial IP really changing
as often as it appears from the logs or is this a problem at your dynamic
address provider?
2:05 p.m.
I don't really know how the portal gets its IP addresses from the
gateway dynamic hostname. Perhaps Chris could enlighten us.
- Brian
On Fri, Jun 09, 2017 at 01:54:34PM -0400, lleachii(a)aol.com wrote:
Brian,
As I noted yesterday:
Could there be a reason the portal keep reverting to the stale data??
Again, to be clear, my IP has not reverted; and no DDNS software is
reporting the old IP.
- Lynwood
KB3VWG
5:39 p.m.
On 9 Jun 2017, at 19:05, Brian Kantor
<Brian(a)UCSD.Edu> wrote:
I don't really know how the portal gets its IP addresses from the
gateway dynamic hostname. Perhaps Chris could enlighten us.
Once an hour a script is run by crontab, it gets a list of all the gateway entries that
have the ‘hostname’ field populated from the database.
The script then does a ‘gethostbyname’ call to resolve the hostname to an IP address.
If this call fails it does nothing more with this gateway and moves on to the next one.
If it successfully resolves the hostname it does the following regexp check:
/^(0\.|10\.|127\.|169\.254\.|192\.168\.|224\.|255\.255\.255\.255)/
and if a match is found it ignores this gateway and moves onto the next one.
This eliminates any “bad” IP addresses getting into the encap file.
If no match is found it looks up the current IP address for the gateway in the database,
if it’s the same as the resolved hostname it does nothing more and moves onto the next
gateway. If however the two IP's are different it updates the database with the new IP
then increments the encap serial.
There is another script run from crontab every 5 minutes that emails the encap file (to
those that have the “when changed” flag set on the portal) and also updates the FTP encap
file, if the encap serial has changed.
The ‘gethostbyname’ call uses the local resolver on the machine to lookup the IP address,
so this effectively comes from our company recursive nameservers, rather than any public
nameservers.
Hope that helps.
Regards,
Chris
10:44 p.m.
What about the RIP44 broadcast? I added a line to log to /var/etc/syslog
when the load_ipipfilter runs this morning. I was concerned I wasn't
getting the broadcasts but it ran at 1320UTC and it ran at 1920UTC so I
think I'm getting them. To verify, are they addressed to the external
address registered in the portal? I want to add an iptables log rule to log
when they come in.
Thanks.
--tom/n2xu
On Fri, Jun 9, 2017 at 18:31 Brian Kantor <Brian(a)ucsd.edu> wrote:
Thanks Chris, that is helpful information.
- Brian
On Fri, Jun 09, 2017 at 10:39:00PM +0100, G1FEF via 44Net wrote:
--
73 de N2XU/Tom Cardinal/MSgt USAF (Ret)/BSCS/Security+/IPv6 Certified
Once an hour a script is run by crontab, it gets
a list of all the
gateway entries that have the ‘hostname’ field populated from the
database.
[...]
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
10:52 p.m.
Tom,
From earlier...
-rw-r--r-- 1 root root 31119 Jun 7 20:20
/etc/config/encap.txt
Now...
-rw-r--r-- 1 root root 31069 Jun 9 16:20
/etc/config/encap.txt
I assume you're in the FL panhandle and you're in Central Time
Zone...so...why are we only receiving routes on 20 on the hour???
- Lynwood
KB3VWG
11:15 p.m.
On Sat, Jun 10, 2017 at 02:44:45AM +0000, Tom C wrote:
What about the RIP44 broadcast? I added a line to log
to /var/etc/syslog
when the load_ipipfilter runs this morning. I was concerned I wasn't
getting the broadcasts but it ran at 1320UTC and it ran at 1920UTC so I
think I'm getting them. To verify, are they addressed to the external
address registered in the portal? I want to add an iptables log rule to log
when they come in.
Thanks.
--tom/n2xu
The RIP44 transmissions originate every 5 minutes as IPIP encapsulated
UDP packets for port 520 from 169.228.34.84 and sent individually to
the commercial (external) address of every gateway. They are IPIP
encapsulated packets, so without de-encapsulating them, the RIP is
not visible.
The content of each transmission is a series of encapsulated packets
with an inner source address of 44.0.0.1 and an inner destination of
224.0.0.9, the RIP multicast address.
There are currently 25 full and one partially-full packets sent to each
gateway. There is a 100-microsecond delay between successive packets.
The total transmission time for all 26 packets to all 433 gateways is
under 2 seconds.
Note that if an ICMP unreachable response to the transmission is received,
no further packets will be sent to that gateway during the current
5-minute cycle, but will resume on the next run 5 minutes later.
A typical packet as seen in tcpdump is below.
- Brian
20:02:04.969185 IP (tos 0x0, ttl 64, id 13740, offset 0, flags [none], proto IPIP (4),
length 552, bad cksum 0 (->4af3)!)
169.228.34.84 > 83.162.216.88: IP (tos 0x0, ttl 255, id 0, offset 0, flags [none],
proto UDP (17), length 532)
44.0.0.1.520 > 224.0.0.9.520:
RIPv2, Response, length: 504, routes: 25 or less
Simple Text Authentication data
AFI IPv4, 44.46.0.11/32, tag 0x0004, metric: 1, next-hop: 216.106.6.183
AFI IPv4, 44.46.17.0/24, tag 0x0004, metric: 1, next-hop: 107.172.42.138
AFI IPv4, 44.46.19.0/24, tag 0x0004, metric: 1, next-hop: 131.151.102.29
AFI IPv4, 44.46.32.0/24, tag 0x0004, metric: 1, next-hop: 75.132.48.79
AFI IPv4, 44.46.64.0/24, tag 0x0004, metric: 1, next-hop: 104.131.81.118
AFI IPv4, 44.46.128.0/24, tag 0x0004, metric: 1, next-hop: 99.98.226.199
AFI IPv4, 44.48.0.10/32, tag 0x0004, metric: 1, next-hop: 205.171.203.226
AFI IPv4, 44.48.0.16/30, tag 0x0004, metric: 1, next-hop: 104.236.122.16
AFI IPv4, 44.48.0.40/29, tag 0x0004, metric: 1, next-hop: 216.252.59.3
AFI IPv4, 44.48.1.0/29, tag 0x0004, metric: 1, next-hop: 98.158.218.169
AFI IPv4, 44.48.5.0/29, tag 0x0004, metric: 1, next-hop: 216.252.59.3
AFI IPv4, 44.48.6.0/29, tag 0x0004, metric: 1, next-hop: 216.252.59.3
AFI IPv4, 44.48.8.0/22, tag 0x0004, metric: 1, next-hop: 96.82.54.108
AFI IPv4, 44.48.12.0/24, tag 0x0004, metric: 1, next-hop: 216.252.59.3
AFI IPv4, 44.48.16.0/24, tag 0x0004, metric: 1, next-hop: 216.252.59.3
AFI IPv4, 44.48.17.0/30, tag 0x0004, metric: 1, next-hop: 216.252.59.3
AFI IPv4, 44.48.18.0/26, tag 0x0004, metric: 1, next-hop: 216.252.59.3
AFI IPv4, 44.48.31.0/30, tag 0x0004, metric: 1, next-hop: 73.146.173.214
AFI IPv4, 44.48.128.0/24, tag 0x0004, metric: 1, next-hop: 104.4.69.20
AFI IPv4, 44.50.0.69/32, tag 0x0004, metric: 1, next-hop: 199.10.4.185
AFI IPv4, 44.50.192.0/27, tag 0x0004, metric: 1, next-hop: 108.160.233.78
AFI IPv4, 44.50.192.128/29, tag 0x0004, metric: 1, next-hop: 199.10.4.185
AFI IPv4, 44.52.11.32/28, tag 0x0004, metric: 1, next-hop: 74.94.164.116
2533
days inactive
2534
days old
7 comments
4 participants
participants (4)
-
Brian Kantor -
G1FEF -
lleachii＠aol.com -
Tom C