On 9 Jun 2017, at 19:05, Brian Kantor Brian@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

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@ucsd.edu wrote:

Thanks Chris, that is helpful information. - Brian

On Fri, Jun 09, 2017 at 10:39:00PM +0100, G1FEF via 44Net wrote:

...

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@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

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