On 2017-05-11 04:13, lleachii--- via 44Net wrote:
(Please trim inclusions from previous messages) _______________________________________________
- Also, I cannot block receipt of RIP44 packets
If you don't want those RIP44 packets, why use ampr-ripd? The current implementation was a change to get it running an all machines, even if they don't support proper multicast handling. I could get the -r option back.
- SECURITY - a malicious person could craft a packet of AGW and still
change routes
Yes, that is a possibility and always was.
- a password is sufficient, so we can still distribute routes via
ampr-ripd
It distributes standard RIP. If you want RIP44, setup a propergateway, or use quagga instead. It can co-exist with ampr-ripd on the same machine. Since RIP needs to be on the same subnet for it to work in multicast mode, one can secure the channel. In unicast mode, you can always filter the RIP source. The password is by no means a security measure, since any plain RIP password can be found by sniffing the traffic.
Feature request:
- keep password default
See above.
- keep the -p argument
The -p argument is still there and works. It is just not needed by default.
- add an argument to include a password in the -f argument packets
(this allows the person to specify a password if they want to receive RIP44 form and agreed 2nd source using the -p argument on their device)
This could be done, but why is this needed? See above.
- KB3VWG
*- OPTION to FIREWALL receipt of IPENCAP on WAN-facing side on Linux machine using iptables/netfilter (broken in 1.15)*
Again, why do you need to firewall something you want? Don't use the daemon if you don't need them. As I said, the -r option can be made active again, but why?
Marius, YO2LOJ