44net

44net@mailman.ampr.org

3196 discussions

Re: [44net] ToS/DSCP
by Rob Janssen 30 May '17

30 May '17

I do not see what all this tracerouting has to do with ToS/DSCP but I can add that we have full support for ToS/DSCP in our local net and it works beautifully. We use the top 3 bits of the ToS/DSCP to split the traffic in 8 queues in a Queue Tree (MikroTik feature) on links with a defined bandwidth, and it is used in WiFi link equipment (Ubiquiti, MikroTik) to split the traffic in 4 queues typically (WMM). We mainly use EF (46) for voice, CS1 (8) for background traffic like backups, and have CS2 (16) for a priority slightly above that. Default 00 is above that priority. I see no latency effects of running a long backup over the same links used for the repeater audio for our co-channel multi site repeaters. Of course DSCP only works as long as it is not abused to get priority over fellow hams. It is like using more power to wipe everyone else from the repeater... works until the others do it too. Rob

3 2

ToS/DSCP
by lleachii＠aol.com 30 May '17

30 May '17

All, I've been doing some testing with the Type of Service and Differentiated Services Code Point for tunl0. I've been working to determine if connectivity to Ronen's camera's could be slightly improved from the tunnel's perspective. I'm focusing on the improvements seen using hex code 0xB8, known as High Priority Expedited Forwarding, or 'Virtual Leased Line.' I wanted you all to check your connections to me, and make sure that I'm still reachable. Feel free to ping, or simply use my tool at http://44.60.44.10/tools/trace/php-trace44.php/ to reach yourselves. 73, - Lynwood KB3VWG > ip tunnel change tunl0 mode ipip ttl 64 tos B8 pmtudisc

3 7

Re: [44net] Mapping experiment proposal
by Rob Janssen 30 May '17

30 May '17

> I can modify ampr-ripd (and amprd if needed) to periodically sent some > data "home", locator and gateway callsign to 44.182.21.1. > This would need an additional parameter, something like "-Lyo2loj at kn05or <http://hamradio.ucsd.edu/mailman/listinfo/44net>". > This would allow me to put together a simple tracking database and show > active nodes on a world map for everybody to gaze at :-) Yes, it could send some fields like the software version and maybe the number of routes it has put in the table, so it will be possible to debug things and be able to notify users when a serious problem is discovered or protocol change is made that requires update beyond some version number. That could be done using MNDP or similar protocol sending to 44.0.0.1? I would recommend having different fields for different information. (sysop, locator, etc) Way I the past I had something like this in my NET version. It used multicast to 224.0.1.31 which is a multicast address I registered for this purpose. host 224.0.1.31 31.1.0.224.in-addr.arpa domain name pointer ampr-info.mcast.net. You are welcome to use that address when required (probably not, just send over tunnel to some real destination or 255.255.255.255) Rob

1 0

Mapping experiment proposal
by Marius Petrescu 30 May '17

30 May '17

If anyone is interested, I would propose an experiment. I can modify ampr-ripd (and amprd if needed) to periodically sent some data "home", locator and gateway callsign to 44.182.21.1. This would need an additional parameter, something like "-L yo2loj@kn05or". This would allow me to put together a simple tracking database and show active nodes on a world map for everybody to gaze at :-) Anyone interested? Marius, YO2LOJ

6 7

Tunnel keep allive
by R P 30 May '17

30 May '17

So with Brians "pressure" on me (HI) i think i have found the problem ... it it the tunnel keep alive and now the questions 1)Does it necessary to turn it on ? 2) why this uses source address of amprGW and destination of my local address maybe its a a bug in the Mikrotik tunnel ? what protocol keep alive uses ? is there anyone else here with mikrotik that have a keep alive open and know if he get same errors from AMPGW ? I have changed the keep alive timing from every 10 to 610 seconds and the errors reduced to 2 every 15 minutes from about 100 Ronen - 4Z4ZQ

3 3

Re: [44net] MikroTik uptime
by Rob Janssen 30 May '17

30 May '17

> Reverse engineering the protocol was a bit of a challenge. I couldn't > find it documented in sufficient detail anywhere and wound up decoding the > protocol format from the hex dump and decoding that wireshark provided. Yes, that is kind of inconvenient. From the wireshark decoding I guessed that it would be a float. Apparently not. Wireshark shows that it is TLV data and what the types mean, and I knew that you would be able to map the TLV to the hexdump. Rob

1 0

Re: [44net] MikroTik uptime
by Rob Janssen 30 May '17

30 May '17

> Thanks Tom, yes, when I assume it's seconds, I get > uptime numbers like 22+02:22:54, which is 22 days, > 2 hours, and some minutes/seconds. Yes, it is in seconds. The latest software release was early may, so that is a uptime that can be expected. Rob

2 1

Re: [44net] Tunnel keep allive
by Rob Janssen 30 May '17

30 May '17

> So with Brians "pressure" on me (HI) i think i have found the problem ... it it the tunnel keep alive > and now the questions > 1)Does it necessary to turn it on ? > 2) why this uses source address of amprGW and destination of my local address maybe its a a bug in the Mikrotik tunnel ? what protocol keep alive uses ? is there anyone else here with mikrotik that have a keep alive open and know if he get same errors from AMPGW ? Yes, that is probably the reason. You should simply turn it off. The tunnel keep alive packets are tunneled packets with source and destination address swapped. There is no standard for this, but it is a method used by other manufacturers as well. Apparently the expectation is that the remote end of the tunnel will just route the packets and return them on the same tunnel, just like a ping. However, in your case one of the addresses is a 192.168 (RFC1918) address. Likely you are running your MikroTik behind another router that does NAT. That is not a good idea, you should try to get the real internet address on the MikroTik. With some ISPs it may be difficult because the use of the provided router is mandatory and it cannot be put in transparent mode. Setting "DMZ mode" in the router often causes additional problems. Rob

1 0

MikroTik uptime
by Brian Kantor 30 May '17

30 May '17

Rob or Marius, do you know what units the MikroTik reports its uptime in? Is it seconds? I get numbers like 1922575 or 1909374 for the two I have MNDP data for. - Brian

2 2

MNDP packets
by Rob Janssen 30 May '17

30 May '17

Maybe one of the interesting "things to do" would be to write a small daemon that captures those UDP packets to 255.255.255.255 port 5678 (MNDP) and stores the latest one received from each source. It would have to have access to the outer IPIP header to do that. Then, it could regularly dump the collected "latest packets" in a tabulated text file with the fields that there are in these packets each in a column. When you look in wireshark (which knows about this format) you see it is quite easy to do. This table would present an overview of the MikroTik routers in use, and could help identify possible problems with the tunneling they do. You could also stop handling them as an error condition. How would such a daemon have to be written so it can run at the gateway? Could it just do a pcap with the appropriate filter? Rob

7 19

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net