Request: separate arp.spoof and arp.ban into individual modules

[lecatos]

Description of the bug or feature request
The description and the title is straight forward.
When I do "ARP.BAN OFF", IT ALSO TURN OFF ARP.SPOOF
idk if this is a bug or they intended to do this but if they intended to do this, I don't want this to happen because I wanted the spoofing to continue to work after I turned off ban mode. I know that I can just do "arp.spoof on" back but I am not fast enough because in my case, the victim device will try to make a http request when it is disconnected (this disconnection is caused by me doing "arp.ban on") and when the victim tries to make a http request, I should do "arp.ban off" to spoof their http request but instead when doing "arp.ban off" it also turn off arp spoofing (arp.spoof) therefore my http spoofing will fail.

In order for my attack to be successful, I will have to manual set "ip_forward" file to 1 which is equivalent to doing "arp.ban off" except this manual way, arp.spoof won't be stopped automatically thus making http spoofing in "my case" possible.

Environment

Please provide:

• Bettercap version you are using ( bettercap -version ).

• bettercap v2.31.0 (built for linux amd64 with go1.13.8)

• OS version and architecture you are using.
  Ubuntu 20.04LTS

• Go version if building from sources.

• go1.13.8

• Command line arguments you are using.

• Caplet code you are using or the interactive session commands.

• Full debug output while reproducing the issue ( bettercap -debug ... ).
  no debug needed

Steps to Reproduce

arp.spoof on
arp.ban on
arp.ban off //also turn off arp.spoof

Expected behavior: What you expected to happen
What I expected to happen is that after I run "arp.ban off", it should only turn off ban mode and not the entire arp spoofing
Actual behavior: What actually happened
it turned off arp spoofing

♥ ANY INCOMPLETE REPORT WILL BE CLOSED RIGHT AWAY ♥

[buffermet]

You can execute multiple commands using a semicolon separator (arp.ban off; arp.spoof on) but in your case, stopping the arp.ban module will begin to restore the ARP cache of those victims, possibly causing some packet loss.

I'll mark this as a suggestion.

[evilsocket]

i could add an option to skip arp cache restoring when turning arp.ban and/or arp.spoof off so you could do what @buffermet here suggested and it'll be quick enough