Fix daemon timer

[jwt27]

Found the DHCP/daemon problem. The timer was being reset every time daemon_run() was called, and therefore would never actually trigger.

What I don't understand, is why this only caused problems on 16-bit systems...

Fixes: #4

[jwt27]

Oh, I think I do know why this "worked" on other platforms. On Pentium+ machines, chk_timeout() will use the rdtsc timer by default, which I noticed before is very inaccurate. So the daemon timer only accidentally triggered due to jitter.

This may also explain why I had some spurious issues in my own code where I used userTimerTick(). Then the daemon code would never trigger either.

[Lethja]

16-bit (Watcom) output:

Parsing `.\wattcp.cfg' (pass 1)
Parsing `.\wattcp.cfg' (pass 2)
ARG_FUNC   , matched `MY_IP' = `dhcp'
rundown_dump():
  order   3: `restore_sig_handlers'  called from sock_ini.c (892)
  order   5: `dbug_exit'  called from pcdbug.c (306)
  order  10: `__eth_release'  called from pcsed.c (704)
  order 259: `DHCP_exit'  called from pcdhcp.c (1435)
  order 303: `exit_localport'  called from ports.c (59)
  order 1000: `daemon_clear_cdecl'  called from sock_ini.c (841)
  okay
Configuring through DHCP..Running daemon 0 (arp_daemon)
Running daemon 1 (dhcp_fsm)
.Running daemon 0 (arp_daemon)
Running daemon 1 (dhcp_fsm)
Running daemon 0 (arp_daemon)
Running daemon 1 (dhcp_fsm)
.Running daemon 0 (arp_daemon)
Running daemon 1 (dhcp_fsm)
value 3232235779 duplicated in array 3621:3ed8
Address: 192.168.1.29
Calling rundown-func `restore_sig_handlers' at order 3
Calling rundown-func `dbug_exit' at order 5
Calling rundown-func `__eth_release' at order 10
Calling rundown-func `DHCP_exit' at order 259
Calling rundown-func `exit_localport' at order 303
Calling rundown-func `daemon_clear_cdecl' at order 1000

Well done!

[gvanem]

The timer was being reset every time daemon_run() was called,

That was a silly mistake with { } code. Tried it with #97 and all seems well with DHCP now. Good job indeed! Merging and closing.