When handling the EV_WINS event, IPCP assumes that the ->wins1 and
->wins2 fields of the event structure are properly set. But that may
not be the case.
If only one of the MS-Primary-NBNS-Server or MS-Secondary-NBNS-Server
RADIUS attributes was received, then only ->wins1 or ->wins2 is set,
while the other keeps a non initialised value. This uninitialised value
is then copied by ev_wins() and proposed to the peer when negociating
the Primary-NBNS-Address or Secondary-NBNS-Address IPCP options.
That leaks four bytes of the stack to the network and prevents using
the values found in the [wins] section of accel-ppp.conf as fallback.

Fix this by initialising the whole event structure in rad_proc_attrs().
Then, in ev_wins(), we can check if ->wins1 or ->wins2 is properly set
before copying them. That allows to propery fallback to accel-ppp.conf
values when one of the values was not provided by RADIUS.
Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>