44net April 2017

44net@mailman.ampr.org

41 participants
78 discussions

Re: [44net] rip sender change
by Rob Janssen 25 Apr '17

25 Apr '17

> Yes, it was intentionally dropped by the daemons. If it will be > reachable, I will update the code accordingly. I see it in the code now, just a couple of lines that can be deleted around line 1346: /* drop 44.0.0.1 */ if (rip->address == inet_addr("44.0.0.1")) { #ifdef HAVE_DEBUG if (debug && verbose) fprintf(stderr, " - rejected\n"); #endif return; } A temporary workaround until everyone has again updated ampr-ripd could be to announce 44.0.0.0/30 instead of 44.0.0.1/32 in the RIP sender. Rob

1 0

Re: [44net] rip sender change
by Rob Janssen 25 Apr '17

25 Apr '17

> ampr-ripd does not set a route for 44.0.0.1, because that IP is not > reachable via the tunnel, only via the internet. Ah, it is treated as a special case? Brian has been working on that problem and now this route is announced again. (it had been deleted from the RIP broadcast before) I think it is added in the RIP sender, maybe it would be better to just register a portal entry so it is in encap.txt as well. Rob

2 1

Re: [44net] more gateway router follies
by Rob Janssen 25 Apr '17

25 Apr '17

What you logged there are probably DHCP packets and private use of RIP, not the AMPR-RIP. Well, I do see a lot of those things here either... Recently I again worked on the filters and found e.g.: - router-sourced traffic with inner source address equal to the external IP (bad source address selection) - router sending some of the traffic outside of the tunnel (net-44 to net-44 traffic unencapsulated) the funny thing is that e.g. when pinging them it returns via the tunnel but when doing BGP the SYN ACKs from port 179 come outside the tunnel. when the sender had proper source address filtering at their ISP I would not see those packets at all. - of course still a lot of traffic with inner source address in RFC1918 range The first two above are blamed on "MikroTik VRF". I never use it, I always use a manual implementation using multiple routing tables, ip routing rules and maybe some mangle rules just as I am used to do on bare Linux, and I don't have those problems. Another group swears by VRF and they always have issues. As I believe MikroTik VRF is just an an automatic configuration of the mentioned features and it apparently does not work completely OK (and may need some help e.g. some extra mangle rule). I tried to get information on what really happens when you define a VRF, but I was unable to get answers. Rob

1 0

Re: [44net] rip sender change
by Rob Janssen 24 Apr '17

24 Apr '17

> Yes, there was an off-by-one error in the count of entries in > the last packet. This error was not present when we were sending > in gateway major order, but was there in packet-major-order which > change I made early today. It has been corrected. Please check > the next RIP update and see if that fixes things. Ok, now I get the correct RIP packet :-) But the entry still does not appear in the route table... :-( IP Address: 44.2.2.0, Metric: 1 Address Family: IP (2) Route Tag: 4 IP Address: 44.2.2.0 (44.2.2.0) Netmask: 255.255.255.0 (255.255.255.0) Next Hop: 24.52.189.1 (24.52.189.1) Metric: 1 IP Address: 44.0.0.1, Metric: 1 Address Family: IP (2) Route Tag: 4 IP Address: 44.0.0.1 (44.0.0.1) Netmask: 255.255.255.255 (255.255.255.255) Next Hop: 169.228.66.251 (169.228.66.251) Metric: 1 44.0.0.0/8 via 213.222.29.193 dev eth0 src 44.137.0.1 44.2.2.0/24 via 24.52.189.1 dev tunl0 proto ampr-ripd metric 4 onlink So now I can continue local debugging to see what is going wrong... It fails both on the gateway (running latest ampr-ripd) and the Raspberry Pi (running earlier version). It does not appear in /var/lib/ampr-ripd/encap.txt either. Never assume there is only one bug... Rob

2 1

Re: [44net] rip sender change
by Rob Janssen 24 Apr '17

24 Apr '17

> Yes, that's very much a mystery, because my tcpdump shows the route > being sent right after the one for 44.2.2.0/24. > [...] > AFI IPv4, 44.2.2.0/24, tag 0x0004, metric: 1, next-hop: 24.52.189.1 > AFI IPv4, 44.0.0.1/32, tag 0x0004, metric: 1, next-hop: 169.228.66.251 Could there be some length or count field that is off by one? I am tracing with wireshark (tshark). But ampr-ripd does not pick it up either. Rob

3 4

Re: [44net] rip sender change
by Rob Janssen 24 Apr '17

24 Apr '17

> Because of concern that the rip sender might be sending > the pseudo-RIP packets to gateways faster than they can > receive them, I have changed the sending order. > ... > This has the effect of inserting a few milliseconds delay > between consecutive packets being sent to any one gateway, > which should give the receiving process more time to handle > the transmission. My main concern was not the receiving process, but the routers in front of the gateway system that (in my case) appeared to drop the tail end of the transmission, probably because of rate limiting or a queue overflow. Now, I get the 26 packets in about 150ms, which should solve that problem for anything but the slowest connections. Thanks! Unfortunately there is still no 44.0.0.1 route. I did a trace and confirm that the last packet received has the lowest addresses, but it ends with: IP Address: 44.2.7.0, Metric: 1 Address Family: IP (2) Route Tag: 4 IP Address: 44.2.7.0 (44.2.7.0) Netmask: 255.255.255.252 (255.255.255.252) Next Hop: 73.185.12.233 (73.185.12.233) Metric: 1 IP Address: 44.2.2.0, Metric: 1 Address Family: IP (2) Route Tag: 4 IP Address: 44.2.2.0 (44.2.2.0) Netmask: 255.255.255.0 (255.255.255.0) Next Hop: 24.52.189.1 (24.52.189.1) Metric: 1 Still some mystery somewhere :-) Rob

2 1

rip sender change
by Brian Kantor 24 Apr '17

24 Apr '17

Because of concern that the rip sender might be sending the pseudo-RIP packets to gateways faster than they can receive them, I have changed the sending order. There are currently 26 packets per gateway per transmission. Instead of sending all packets to a gateway, then sending them to the next gateway, and so on, now each packet is sent to each individual gateway before the next packet is generated and sent. This has the effect of inserting a few milliseconds delay between consecutive packets being sent to any one gateway, which should give the receiving process more time to handle the transmission. The same total data is sent, so nobody should miss out on any routes. Thanks to Rob, PE1CHL for suggesting this technique. - Brian

1 0

Re: [44net] Enabling traffic from inet to 44-net and vice versa
by Rob Janssen 23 Apr '17

23 Apr '17

> My understanding is that it's working correctly, because the icmp reply > is sent back to 2.238.198.249 inside the tunnel and towards the > amprnet router (169.228.66.251). > Unfortunately there's something wrong in the middle because no packets > are actually reaching 2.238.198.249 It must be something in your 2.238.198.249 system or the path to it, because I can ping 44.134.160.1 without problem from other internet hosts. Rob

5 8

Open Source IP Address Management tool
by Bill Vodall 23 Apr '17

23 Apr '17

I don't remember seeing PHPIPAM mentioned here before. (And I searched...) https://phpipam.net/ Perhaps it would be useful - if not for the overall process for local or regional LANS. 73 Bill, WA7NWP

1 0

UDP PORT 5060 ?
by R P 22 Apr '17

22 Apr '17

I think I have asked it before but i see on the log a lot of incoming UDP port 5060 to all the hosts (even that are not active currently but defined in the AMPR dns and therefore have routing to my gateway ) from all over the world What is it ? who have interest to look for SIP on my system ? Is there a way to cut and paste part of the log of Mikrotik router ? i can not do it when i enter it from the web interface so could not copy the relevant log part Thanks Forward Ronen - 4Z4ZQ http://www.ronen.org Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/> www.ronen.org ronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com

4 3

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net April 2017