The result of converting the IP address of the broker wasn't checked. As a result, the pointer was left uninitialised and the IPv6 address used for connecting was some random data. The function now returns an error. Before connect_to_broker is called, mqtt_register is executed, which memsets conn to 0, making its state 0 (MQTT_CONN_STATE_ERROR). In order to recover from this error state, the extra check was added in the MQTT_CLIENT_STATE_NEWCONFIG state.
This was discovered using [CodeSonar](https://www.grammatech.com/products/codesonar)
When a connection is aborted by the HTTP server while it's still being processed it is possible to hit a null pointer dereference issue by jumping back to a protothread (outputpt) after its httpd_state has been freed. This can be triggered by sending a POST to any form in the CC26xx web demo server using Firefox.
This patch prevents that by zeroing out httpd_state structs before freeing them, thus also clearing the httpd_state->outputpt field.
Tested using Firefox 55.0a1 on a CC2650 LaunchPad.
update for MAC symbol counter. Basic functions for get/set-value
parameter setting added. SPI radios needs to be tested.
modified: cpu/avr/radio/rf230bb/atmega256rfr2_registermap.h
modified: cpu/avr/radio/rf230bb/rf230bb.c
1. The PT_MQTT_WAIT_SEND() macro has several issues:
- It does not check the return value from process_post(), which
sometimes returns an error code. See next issue.
- Each time the macro is called, is posts an event to itself. The idea
seems to be that the event should be absorbed by the macro itself, so
when the macro terminates there is NOT a net growth of the event
queue. This does not work. The reason is that the
PROCESS_WAIT_EVENT() sometimes absorbs a broadcast event instead of
its own event, and then the number of events in the event queue
increases. This leads to event explosions and overflow in the event
queue.
- The macro cannot call PT_EXIT(). This will expand to a return
statement, causing a return from the function calling the macro
(mqtt_process), rather then exiting the protothread (which was
probably the intention). Protothreads have lexical scope...
Fixes: 1) Check return value from process_post() 2) Loop until the
event posted to itself is absorbed (rather than just absorbing the
next event) 3) Replace PT_EXIT() with PT_INIT() (doesn't really make a
difference, could probably just be removed).
2. Change order of the checks in the protothread-calling loops in
mqtt_process(). Reason: When a protothread has been cleared by
PT_MQTT_WAIT_SEND(), it will not return a value, so checking against
PT_EXITED does not make sense.
3. PT_MQTT_WRITE_BYTES() should initialize conn->out_write_pos to 0.
When PT_MQTT_WRITE_BYTES() does not finish (due to TCP disconnect for
instance), it may leave conn->out_write_pos with a non-zero
value. Next time PT_MQTT_WRITE_BYTES() is called, it will take data
from the wrong place.
4. Put MQTT_CONN_STATE_ABORT_IMMEDIATE before
MQTT_CONN_STATE_NOT_CONNECTED in the enum list, so that the check
if(conn->state > MQTT_CONN_STATE_NOT_CONNECTED) in mqtt_connect()
fails when in state MQTT_CONN_STATE_ABORT_IMMEDIATE. Otherwise, it
will deadlock and not reattempt connections while in this state.
When UIP_ND6_SEND_NS is enabled, I've noticed that unreachable
neighbours still remains in REACHABLE state even if lifetime
(nbr->reachable) expired.
During network init 'tcpip_process' is scheduling
'uip_ds6_timer_periodic' is to tick every 100ms and make necessary
expirations.
When MAC addres is received from slip-radio (from 'etimer_process'
context), network is "reinitialized" and timer 'uip_ds6_timer_periodic'
is set again with wrong process.
