44net

44net@mailman.ampr.org

3198 discussions

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

Re: [44net] MNDP packets
by Rob Janssen 30 May '17

30 May '17

> 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

2 1

Re: [44net] MNDP packets
by Rob Janssen 30 May '17

30 May '17

> 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

1 0

Re: [44net] MNDP packets
by Rob Janssen 30 May '17

30 May '17

> 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

2 1

Re: [44net] MNDP packets
by Rob Janssen 30 May '17

30 May '17

> 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

1 0

need help in AMPRGW statistics PCAP decode (gateway errors)
by R P 30 May '17

30 May '17

I get the following error in the statistic file of amprgate 5.29.18.144 169.228.66.251 4122 [19] dropped: non-44 inner source address when i look on the PCAP file here is what I see #1 0.000000 169.228.66.251 -> 192.168.1.180 IPv4 20 #2 9.996091 169.228.66.251 -> 192.168.1.180 IPv4 20 #3 19.997040 169.228.66.251 -> 192.168.1.180 IPv4 20 #4 29.996386 169.228.66.251 -> 192.168.1.180 IPv4 20 #5 39.995885 169.228.66.251 -> 192.168.1.180 IPv4 20 #6 49.997226 169.228.66.251 -> 192.168.1.180 IPv4 20 #7 59.996845 169.228.66.251 -> 192.168.1.180 IPv4 20 #8 69.996284 169.228.66.251 -> 192.168.1.180 IPv4 20 #9 79.996422 169.228.66.251 -> 192.168.1.180 IPv4 20 #10 90.006277 169.228.66.251 -> 192.168.1.180 IPv4 20 #11 99.996794 169.228.66.251 -> 192.168.1.180 IPv4 20 #12 109.996173 169.228.66.251 -> 192.168.1.180 IPv4 20 #13 120.008209 169.228.66.251 -> 192.168.1.180 IPv4 20 #14 129.997756 169.228.66.251 -> 192.168.1.180 IPv4 20 #15 139.996572 169.228.66.251 -> 192.168.1.180 IPv4 20 inside the PCAP here is what I see Frame 1: 20 bytes on wire (160 bits), 20 bytes captured (160 bits) Encapsulation type: Raw IP (7) Arrival Time: May 29, 2017 08:59:04.652285000 CEST [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1496041144.652285000 seconds [Time delta from previous captured frame: 0.000000000 seconds] [Time delta from previous displayed frame: 0.000000000 seconds] [Time since reference or first frame: 0.000000000 seconds] Frame Number: 1 Frame Length: 20 bytes (160 bits) Capture Length: 20 bytes (160 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: raw:ip] Raw packet data Internet Protocol Version 4, Src: 169.228.66.251, Dst: 192.168.1.180 0100 .... = Version: 4 .... 0101 = Header Length: 20 bytes Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT) 0000 00.. = Differentiated Services Codepoint: Default (0) .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0) Total Length: 20 Identification: 0x0000 (0) Flags: 0x00 0... .... = Reserved bit: Not set .0.. .... = Don't fragment: Not set ..0. .... = More fragments: Not set Fragment offset: 0 Time to live: 255 Protocol: IPIP (4) Header checksum: 0x0caa [validation disabled] [Good: False] [Bad: False] Source: 169.228.66.251 Destination: 192.168.1.180 [Source GeoIP: La Jolla, CA, United States, AS7377 University of California, San Diego, 32.880699, -117.235901] [Source GeoIP City: La Jolla, CA] [Source GeoIP Country: United States] [Source GeoIP AS Number: AS7377 University of California, San Diego] [Source GeoIP Latitude: 32.880699] [Source GeoIP Longitude: -117.235901] [Destination GeoIP: Unknown] Collapse Tree I dont understand what is the problem May anyone help ? Thank Forward Ronen - 4Z4ZQ

4 6

PCAP viewer ?
by R P 29 May '17

29 May '17

Hi Someone know if there is somewhere on the net something that (web page) can view PCAP file ? If not is there any Software that doesn't need to be installed (unlike WireShark) for PC ? Thanks for Any info Ronen - 4Z4ZQ

2 1

Re: [44net] MNDP packets
by Rob Janssen 29 May '17

29 May '17

> there have only been 8 hosts sending broadcast destination packets Maybe some have turned this off (easy to do) because they are considered errors now. > I don't know if it would be worth the effort to decode them into a text > file since they are already available for download. > What information is in them that might be of general interest? Well, as also suggested by Lynwood, these packets (and others) can be used to maintain a table of software in use, and can be helpful when there is some problem that appears to affect part of the gateways, but it is not immediately clear what they have in common. Rob

1 0

message to all gateway operators
by Brian Kantor 29 May '17

29 May '17

The following message is being queued for email delivery to everyone registered on the portal as operating a gateway. - Brian -------------------------------------------------------------------- From: Brian Kantor <Brian(a)UCSD.Edu> To: AMPRNet Gateway Operators:; Subject: AMPRNet - Important notice regarding your gateway system Hello. You are receiving this email because you are registered with portal.ampr.org as operating an IPIP encapsulating gateway, and there are changes coming that will affect the operation of your gateway. We are replacing the equipment at the UCSD Internet-AMPRNet gateway with a newer, more capable device. In the process, the new equipment will be assigned a NEW IP ADDRESS. You will have to make changes in YOUR gateway configuration for your gateway to continue functioning. The new equipment is already in service as amprgw.ucsd.edu and is on IP address 169.228.34.84. This replaces the old equipment, known as amprgw.sysnet.ucsd.edu, on IP address 169.228.66.251. What you have to do to maintain the operability of your gateway: 1. You must change the outgoing destination address of your gateway from 169.228.66.251 to 169.228.34.84. You may do this immediately; the new equipment at UCSD is already operational. 2. You must allow packets from the new address, 169.228.34.84, into your gateway router software configuration. If you are running with a firewall, you must open a new path through it to your equipment. Packets (RIP44 transmissions) are already being sent to you from this address. 3. You must continue to accept packets from the old address, 169.228.66.251, for a period of a few weeks as the changeover is being made. After a few weeks, packets will stop coming from that address and you may remove permission for them to enter your firewall, if you have one. These are simple changes, involving editing a few configuration parameters, but because there are so many different types of gateway in operation on AMPRNet, how to make these changes cannot be detailed here. You may find more information regarding your particular configuration on https://wiki.ampr.org/ or on the 44net(a)hamradio.ucsd.edu discussion mailing list, which you should join if you are not already a subscriber. Best wishes and 73, - Brian

3 3

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net