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
> 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
> 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
> 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
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
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
> Why my Mikrotik dont appear in this data ?
When you are using Marius' automatic tunnel configuration script, you won't appear there.
It disables the MNDP transmission on the tunnels.
What you see in that list is only those routers where an IP tunnel to the new gateway was
manually configured and MNDP was not turned off.
Rob
> Researching, I believe I noticed 44.137.1.80/28 appear, and that you're
> the coordinator.
> Otherwise, there's already a route existing in the portal.
I know, I will try to contact him to see if he has problems.
(I guess he has only made a tunnel to amprgw. I cannot ping him from a Dutch AMPRnet IP)
Some people apply for a subnet on IPIP and then find that it is not as easy as they
would have guessed to get it working correctly. Probably they expected it would be a
matter of configuring an IP tunnel in their router. We know there is a little more to it.
Rob
> Well, what I wrote does this:
> 68.100.10.100 44.62.5.1 5678 MikroTik 6.36.1 (stable) MikroTik 5RRB-VMWG RB750Gr3 UCSD
> 84.106.126.184 44.137.1.92 5678 MikroTik 6.38.5 (stable) MikroTik V2P4-7CQK RB2011UiAS-2HnD ucsd-gw
> As far as MikroTik router gateways go, that's pretty much all there is
> to be learned from the MNDP broadcasts.
Believe it or not, that already reveals 1 issue and one possible issue...
That second entry has an unregistered address as the router address, and it is likely only having a
single tunnel towards ucsd instead of a full mesh.
Rob
> I forgot: the firmware version, too.
And the router IP address. That is interesting information as it allows us to check
if the gateway is up and actually functioning. The receiving of these MNDP packets in
fact is some indication of that.
Of course the number of gateways using MikroTik routers is low, but maybe when similar
packets were sent by ampr-ripd there would be info from a lot of gateways.
I thought it might be useful to have some status overview and maybe version information.
It can help answer basic questions like "how many of the registered gateways are
actually operational".
Of course it has to be decided if it is worth the extra traffic and the trouble of
writing the software.
About gathering service information: there is some demand for an overview of services
available on AMPRnet. People have suggested installing a search engine, and it has been
done in some places, but IMHO a search engine, while useful, is not really the answer.
When you do not know what to search for, a search engine has to be very clever to give
useful results for queries like "show me an interesting service to try today".
What I am looking for is more like a website that shows a table of services, one line
per service and with a clickable link that expands one item into more detail, describing
interesting services (not limited to websites!) on AMPRnet. Things that draw your
attention and that you may want to try.
The detail would include things like "how to get an account" (when relevant) etc.
It could be constructed in a similar way to the neighbor table maintained by MNDP,
except it would not be UDP broadcasts but e.g. some HTTP POST. When you have a service
that is available on AMPRnet, you would do an automated daily POST of a small file
describing the service (would be easy to install as a cron job using curl or wget)
to the server, and the webpage shows all services that have recently been (re-)posted.
The result would be similar to the Wiki page http://wiki.ampr.org/wiki/Services ,
but with the advantage that services that have become unavailable will disappear from
the list automatically (assuming that the posting of the info is done from the system
providing the service and stops at the same time).
The beauty of a network of course is that anyone can make this and put it online.
It does not have to run on amprgw or other parts of the network infrastructure,
it can just be an experiment running on a Raspberry Pi at someone's home.
When we have something like that, it is easier to get people going after they have
connected to the network, and keeping them interested in exploring new things on the
network. Maybe suitable software already exists, otherwise it should be quite easy
to do on a LAMP server or similar.
Rob
