Recently I noticed people sending IGMP protocol packets to amprgw, which discards them (as it does for all multicast destinations sent to it).
I don't think I'm going to write the necessary code to handle group membership, so dropping the packet is probably the best thing to do.
Amprgw currently does NOT send 'destination unreachable' ICMP packets, including 'protocol unreachable', because those should be rate limited which makes coding the necessary response mechanism somewhat complicated. (True, I could steal the necessary code from the FreeBSD kernel and adapt it, but that's a lot of work. Maybe someday.) And I also don't want to use up encap bandwidth sending ICMP back to the AMPR hosts.
The only ICMP that amprgw currently will originate is TIMXCEED when an encapped packet's TTL reaches zero, so that 'traceroute' will work. - Brian
Actually that's not people sending it :-)
It is a side effect of opening a multicast socket for receiving the RIP messages and happens automatically. Such a sockets will subscribe to the RIP multicast group and maintain this subscription periodically. Basically there is nothing to do to avoid it.
Marius, YO2LOJ
On 2017-04-28 20:04, Brian Kantor wrote:
(Please trim inclusions from previous messages) _______________________________________________ Recently I noticed people sending IGMP protocol packets to amprgw, which discards them (as it does for all multicast destinations sent to it).
I don't think I'm going to write the necessary code to handle group membership, so dropping the packet is probably the best thing to do.
Amprgw currently does NOT send 'destination unreachable' ICMP packets, including 'protocol unreachable', because those should be rate limited which makes coding the necessary response mechanism somewhat complicated. (True, I could steal the necessary code from the FreeBSD kernel and adapt it, but that's a lot of work. Maybe someday.) And I also don't want to use up encap bandwidth sending ICMP back to the AMPR hosts.
The only ICMP that amprgw currently will originate is TIMXCEED when an encapped packet's TTL reaches zero, so that 'traceroute' will work.
- Brian
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net