Ettercap/ettercap — pull request #501 by koeppea (2014-03-08 08:48:13+00:00)
Title: Some timer inconsistencies

First I recognized that the **arp_storm_delay** is being used differently than it's defined in the *etter.conf*.
It's even used differently within the various places in the code. Once it's used as seconds, then it's used as milliseconds but then for `usleep` it's used as microseconds..... so started to fix this.

Then I wondered the default value for **arp_storm_delay** being very high if I take the `#seconds` definition in *etter.conf* for granted. I cross-checked the man-page for :
```
arp_storm_delay The value represents the milliseconds to wait between two consecutive packets
during the initial ARP scan. You can increment this value to be less aggressive
at startup. The randomized scan plus a high delay can fool some types of ARP
scan detectors.
```
OK milliseconds make much more sense. The comment in etter.conf must be an error. Then I started to align all **arp_storm_delay** timers, but while moving through the code I uncovered similar inconsistencies with other timing options.
Then I had the idea to normalize the conversions of the different time units by introducing some stupid MACROS with proper namings that free the programmers mind and so makeing less errors.

I hope I got all timer definitions. It might be the case the the behaviour changed here and there slightly as **arp_storm_delay** has been misused as seconds and now as milliseconds but I found no occurance where the change didn't made sense:
**plug-ins/rand_flood/rand_flood.c**
```c
#if !defined(OS_WINDOWS)
struct timespec tm;
tm.tv_sec = GBL_CONF->port_steal_send_delay;
tm.tv_nsec = 0;
#endif
```

Waiting for 2000 seconds can not make much sense.