29 May
2017
29 May
'17
3:41 p.m.
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
29 May
29 May
4:12 p.m.
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
4:40 p.m.
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
5:13 p.m.
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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
5:22 p.m.
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
5:56 p.m.
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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
6:59 p.m.
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
9:25 p.m.
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
9:49 p.m.
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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
10:35 p.m.
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
11:04 p.m.
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.
30 May
30 May
1:26 a.m.
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.
1:45 a.m.
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.
3:53 a.m.
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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
4:15 a.m.
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(a)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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
6:58 a.m.
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 ?
7:41 a.m.
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
7:55 a.m.
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
>
> 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
>
>
>
2545
days inactive
2546
days old
19 comments
7 participants
participants (7)
-
Brian Kantor -
David Ranch -
lleachii＠aol.com -
Marius Petrescu -
R P -
Rob Janssen -
Ruben ON3RVH