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
An interesting idea. I'm already capturing and storing those packets in pcap files as part of the router error logging, under the heading of 'inner destination broadcast address'. I think it would be a relatively simple thing to do to separate them out by the UDP port number.
However, there aren't all that many gateways sending them. (In the last day, there have only been 8 hosts sending broadcast destination packets to the UCSD gateway, and I don't know how many of them are sending to port 5678.) I suppose that some sort of post-capture-analysis could examine the already-generated error pcap files and separate those MNDP packets out and put them into a separate file.
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? - Brian
On Mon, May 29, 2017 at 09:41:29PM +0200, Rob Janssen wrote:
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
Brian, Rob, et all,
You all may wish to check your IPs at https://shodan.io/
Quite a few already are known. Perhaps an API could be written to save the hassle. Are the MikroTik Ops saying that they send a "neighbor" packet to us?
We may be able to aggregate all the "neighbor packets" (e.g. CBD neighbor, Juniper, etc.) into a REALLY VIABLE application, perhaps ampr-ripd can also be configured to send a "neighbor packet" in the future.
- Lynwood KB3VWG
Hello Brian,
Is the goal here to identify and get these packets stopped or is the group softening their stance of accepting the receipt/response of MNDP (Miktotik), Avahi (Linux)/Bonjour(Apple), LLDP (standard routing link advertisements), CDP, etc?
--David KI6ZHD
On 05/29/2017 01:12 PM, Brian Kantor wrote:
(Please trim inclusions from previous messages) _______________________________________________ An interesting idea. I'm already capturing and storing those packets in pcap files as part of the router error logging, under the heading of 'inner destination broadcast address'. I think it would be a relatively simple thing to do to separate them out by the UDP port number.
However, there aren't all that many gateways sending them. (In the last day, there have only been 8 hosts sending broadcast destination packets to the UCSD gateway, and I don't know how many of them are sending to port 5678.) I suppose that some sort of post-capture-analysis could examine the already-generated error pcap files and separate those MNDP packets out and put them into a separate file.
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?
- Brian
On Mon, May 29, 2017 at 09:41:29PM +0200, Rob Janssen wrote:
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
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On Mon, May 29, 2017 at 02:13:50PM -0700, David Ranch wrote:
Is the goal here to identify and get these packets stopped or is the group softening their stance of accepting the receipt/response of MNDP (Miktotik), Avahi (Linux)/Bonjour(Apple), LLDP (standard routing link advertisements), CDP, etc? --David KI6ZHD
Well, my point of view up to now has been that broadcast packets of any kind don't belong being sent off the local network, particularly not to amprgw. Fact is, some people are doing so, in my opinion because their gateway is misconfigured. That's why I log them as errors.
Rob seems to think there's some value in tabulating the data contained in those packets at amprgw and presenting it in some form for troubleshooters and the curious. I'm not yet convinced. - Brian
I've always viewed that these advertisement packets could help users fine services that are available on the AMPR system on a dynamic fashion vs. a static listing on the AMPR Wiki. The analogy here would be the static encaps.txt route file vs using RIP44. Having something ingest these packets on the UCSD system and update some login-required HTML or txt file could be pretty slick.
--David KI6ZHD
On 05/29/2017 02:22 PM, Brian Kantor wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Mon, May 29, 2017 at 02:13:50PM -0700, David Ranch wrote:
Is the goal here to identify and get these packets stopped or is the group softening their stance of accepting the receipt/response of MNDP (Miktotik), Avahi (Linux)/Bonjour(Apple), LLDP (standard routing link advertisements), CDP, etc? --David KI6ZHD
Well, my point of view up to now has been that broadcast packets of any kind don't belong being sent off the local network, particularly not to amprgw. Fact is, some people are doing so, in my opinion because their gateway is misconfigured. That's why I log them as errors.
Rob seems to think there's some value in tabulating the data contained in those packets at amprgw and presenting it in some form for troubleshooters and the curious. I'm not yet convinced.
- Brian
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Assuming that all of these advertisements present themselves as broadcast packets, it would be possible to simply analyze the existing pcap files, perhaps once a day at the end of the day, and prepare a report of what was found. All the necessary data is already contained in the pcap files.
That way I don't have to make any significant changes to the router nor write a new daemon. All I'd have to do to the router is stop reporting them as errors. It's an idea.
There's a few things we probably DON'T want to report; for example, one gateway is currently advertising that its SMB services are available. I regard that one as asking for trouble. - Brian
On Mon, May 29, 2017 at 02:56:27PM -0700, David Ranch wrote:
I've always viewed that these advertisement packets could help users fine services that are available on the AMPR system on a dynamic fashion vs. a static listing on the AMPR Wiki. The analogy here would be the static encaps.txt route file vs using RIP44. Having something ingest these packets on the UCSD system and update some login-required HTML or txt file could be pretty slick.
--David KI6ZHD
David, Surveying the existing pcap files, the only UDP ports that are being broadcast currently are 138, 5678, and 10001. These don't seem very useful. - Brian
On Mon, May 29, 2017 at 02:56:27PM -0700, David Ranch wrote:
I've always viewed that these advertisement packets could help users fine services that are available on the AMPR system on a dynamic fashion vs. a static listing on the AMPR Wiki. The analogy here would be the static encaps.txt route file vs using RIP44. Having something ingest these packets on the UCSD system and update some login-required HTML or txt file could be pretty slick.
--David KI6ZHD
Understood but if we started advising users to enable Avahi, MNDP, etc. to UCSD's IP, you would start to see richer data. The question is.. can these different protocols be configured to only send these advertisements (broadcasts) to the UCSD IP vs. everyone.
--David KI6ZHD
On 05/29/2017 06:25 PM, Brian Kantor wrote:
(Please trim inclusions from previous messages) _______________________________________________ David, Surveying the existing pcap files, the only UDP ports that are being broadcast currently are 138, 5678, and 10001. These don't seem very useful.
- Brian
On Mon, May 29, 2017 at 02:56:27PM -0700, David Ranch wrote:
I've always viewed that these advertisement packets could help users fine services that are available on the AMPR system on a dynamic fashion vs. a static listing on the AMPR Wiki. The analogy here would be the static encaps.txt route file vs using RIP44. Having something ingest these packets on the UCSD system and update some login-required HTML or txt file could be pretty slick.
--David KI6ZHD
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On Mon, May 29, 2017 at 06:49:54PM -0700, David Ranch wrote:
Understood but if we started advising users to enable Avahi, MNDP, etc. to UCSD's IP, you would start to see richer data. The question is.. can these different protocols be configured to only send these advertisements (broadcasts) to the UCSD IP vs. everyone. --David KI6ZHD
As far as I can see, you can't enable these services to a specific IP, you enable them to a multicast or broadcast address that is defined for the particular service.
According to some of the online info, these typically have to be enabled on a per-interface basis. Whether they would get forwarded from a host sending one of them through a gateway router and then to UCSD is an iffy question - most of the stuff I saw on line was about being sure to block such traffic with various interface configurations and firewall rules.
And as you say, you probably don't want to forward them down every tunnel you have access to, just to the one at UCSD, and that's a whole bag of worms in itself, when you consider that for most Linux gateways, it's the same interface for all tunnels.
Mikrotik might be different because you have to have one tunnel interface per destination tunnel, and presumably you could enable MNDP on just the one facing UCSD, but I'm not sure there's much to be learned from MNDP except perhaps the model of Mikrotik in use.
For Avahi and such, I see many difficulties. - Brian
You can actually see the router model, router ID, interface name, and uptime.
On 30.05.2017 05:35, Brian Kantor wrote:
Mikrotik might be different because you have to have one tunnel interface per destination tunnel, and presumably you could enable MNDP on just the one facing UCSD, but I'm not sure there's much to be learned from MNDP except perhaps the model of Mikrotik in use.
That's true. The intent of those packets was to allow device discovery for their configuration utility, and never leave the local network (as any broadcast btw).
If we really want a tracking/monitoring tool, we should check our requirements and write the proper tool. As Lynwood suggested, such component could be included in the ampr-ripd and ampr daemons, or created as a standalone tool, to allow some kind of client announcement/registration (e.g. as a JSON content including elements such callsign, serviced subnets or others).
If we really need such thing is another question.
Marius On 30.05.2017 06:09, Brian Kantor wrote:
If I hadn't already written it, I'd question the value of a daemon gathering that data....
- Brian
On Tue, May 30, 2017 at 06:04:51AM +0300, Marius Petrescu wrote:
You can actually see the router model, router ID, interface name, and uptime.
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. - Brian
On Tue, May 30, 2017 at 08:26:13AM +0300, Marius Petrescu wrote:
That's true. The intent of those packets was to allow device discovery for their configuration utility, and never leave the local network (as any broadcast btw).
If we really want a tracking/monitoring tool, we should check our requirements and write the proper tool. As Lynwood suggested, such component could be included in the ampr-ripd and ampr daemons, or created as a standalone tool, to allow some kind of client announcement/registration (e.g. as a JSON content including elements such callsign, serviced subnets or others).
If we really need such thing is another question.
Marius On 30.05.2017 06:09, Brian Kantor wrote:
If I hadn't already written it, I'd question the value of a daemon gathering that data....
- Brian
On Tue, May 30, 2017 at 06:04:51AM +0300, Marius Petrescu wrote:
You can actually see the router model, router ID, interface name, and uptime.
Why my Mikrotik dont appear in this data ?
________________________________ __ 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
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Is the discover service active on the AMPR gateway ipip interface? If not, that might be why :) Mine isn't shown either, but that is by design. I turned off discovery for all IPIP tunnel interfaces
73,
Ruben - ON3RVH
-----Original Message----- From: 44Net [mailto:44net-bounces+on3rvh=on3rvh.be@hamradio.ucsd.edu] On Behalf Of R P Sent: dinsdag 30 mei 2017 9:54 To: AMPRNet working group 44net@hamradio.ucsd.edu Subject: Re: [44net] MNDP packets
(Please trim inclusions from previous messages) _______________________________________________ Why my Mikrotik dont appear in this data ?
________________________________ __ 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
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Ronen,
Sorry to say, but you are still sending some of your outbound traffic through old amprgw. Your gateway actually appears in BOTH routers, old and new. This is strange.
The MikroTik MNDP packets that you're sending are going through new amprgw and are being discarded because they have an all-zero inner source address. This is also strange.
On the other hand, the packets you're still sending through old amprgw have an inner source address of 169.228.66.251 (which is wrong) and an inner destination address of 192.168.1.180 (which is also wrong). They are also exactly 20 bytes long, in other words, they are just IP headers with no data. They are also for protocol 4, which is wrong. This is even more strange.
I have no explanation for why these things are occuring. - Brian
On Tue, May 30, 2017 at 07:53:35AM +0000, R P wrote:
Why my Mikrotik dont appear in this data ?
Dear Brian (and all other experts )
I really dont know where the problem is
I have shut down the router for two hours and indeed no errors appeared
I dont notice any connection problem so from my point of view no problem that i can search for
The only two changes i have done the last few days were
1) routing my outbound traffic to the new GW address (that required creating additional tunnel to the new address )
2) upgrading the router firmware from 6.34.4 to 6.39.1
I will try first to return the system to route only to old AMPRGW and later try to downgrade the firmware to what it was before (6.34.4)
I have no NAT enabled (i thought it was NAT related) and have no 169.228.66.251 address definition beside in the tunnel definition as "tunnel remote address" and the 192.168.1.180 is my router local net IP and the "tunnel local address"
I have keep alive in the tunnel turned on and it is every 10 seconds so if there is a correlation between the error rate and the keep alive maybe its a clue (is keep alive mechanism is only headers ?) i will change it to see if the errors will drop so maybe i have a clue
I have made yesterday a firewall rule to catch every outbound traffic with 169.228.66.251 source address and even no one packet was logged for the whole night
definitely it is for me a "school" ....
Im open for any suggestions ...
If I give up (not so quick) and the situation will stay as it is it hope you will not be angry with me as my gateway makes some noise in the up-going stream path
Regards
Ronen - 4Z4ZQ
________________________________
I have no explanation for why these things are occuring. - Brian
I'm sorry, Ronen, I'm not an expert with MikroTik. I have no actual experience with one. (I do own one but I've never put it into service.)
I don't think you should downgrade the firmware back to the old version. I really doubt that was the cause of any of the problems you are experiencing.
I don't think you should go back to routing through old amprgw because it's going to go away in a few days (I don't yet know exactly when) and you would be disconnected as a result.
The strange things going on with your router are not causing problems for anyone, so don't feel that you need to shut down because of them. It would be nice if you could find the cause and fix it but it is not urgent.
Please don't give up. It's mostly working. - Brian
On Tue, May 30, 2017 at 11:41:03AM +0000, R P wrote:
Dear Brian (and all other experts )
I really dont know where the problem is
I have shut down the router for two hours and indeed no errors appeared
I dont notice any connection problem so from my point of view no problem that i can search for
The only two changes i have done the last few days were
routing my outbound traffic to the new GW address (that required creating additional tunnel to the new address )
upgrading the router firmware from 6.34.4 to 6.39.1
I will try first to return the system to route only to old AMPRGW and later try to downgrade the firmware to what it was before (6.34.4)
I have no NAT enabled (i thought it was NAT related) and have no 169.228.66.251 address definition beside in the tunnel definition as "tunnel remote address" and the 192.168.1.180 is my router local net IP and the "tunnel local address"
I have keep alive in the tunnel turned on and it is every 10 seconds so if there is a correlation between the error rate and the keep alive maybe its a clue (is keep alive mechanism is only headers ?) i will change it to see if the errors will drop so maybe i have a clue
I have made yesterday a firewall rule to catch every outbound traffic with 169.228.66.251 source address and even no one packet was logged for the whole night
definitely it is for me a "school" ....
Im open for any suggestions ...
If I give up (not so quick) and the situation will stay as it is it hope you will not be angry with me as my gateway makes some noise in the up-going stream path
Regards
Ronen - 4Z4ZQ
I have no explanation for why these things are occuring. - Brian
-
Brian Kantor -
David Ranch -
lleachii＠aol.com -
Marius Petrescu -
R P -
Rob Janssen -
Ruben ON3RVH