Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem


DHCP.c 0831- attempt to close socket but socket not open

Posted by glenenglish on September 5, 2016

Found this one when I patched in the new +TCP 0831 and associated DHCP changes. an easy one to find.

in vDHCPProcess state == eWaitingSendFirstDiscover

If xApplicationDHCPHook returns at eDHCPPhase==eDHCPPhasePreDiscover which sets xGivingUp==true

Down the bottom of vDHCPProcess

xGivingUp is checked and if true, then the socket is closed.

BUT !!!! prvInitialiseDHCP(); was never called, because of the initial eDHCPUseDefault return from the hook so the socket never gets born.

Until I have a good look at the best way to deal with this (maybe change code path )

really needs an assert if there is an attept to close a open socket.

I have put in /* hack by GLEN / / only close socket if it was opened... */ if (xDHCPData.xDHCPSocket!=NULL) { vSocketClose( xDHCPData.xDHCPSocket ); xDHCPData.xDHCPSocket = NULL; }



DHCP.c 0831- attempt to close socket but socket not open

Posted by kerub on September 6, 2016

I think the problem is somewhere else.

The function vSocketClose do nothing if the socket is equal NULL

if( ( xSocket == NULL ) || ( xSocket == FREERTOS_INVALID_SOCKET ) )
	xResult = 0;

The socket xDHCPData.xDHCPSocket is set first to NULL after first attempt to close the socket.

The problem is the stucture xDHCPData has no defined values at the start of the system.

static DHCPData_t xDHCPData;

So it does't guarantiee that xDHCPData.xDHCPSocket is NULL before first use.

In a static analysis of the code it would be reported as an error.


DHCP.c 0831- attempt to close socket but socket not open

Posted by richard_damon on September 6, 2016

Point of information. xDHCPData above is declared as a static variable, so the C language defines that it will be zero initialized at startup, so pointer members should be NULL. (If it was declared in block scope with auto duration, then yes, it doesn't get initialized, but file/global scoped variables are supposed to be zero initialized if not otherwise initiaized).

There are some embeded enviroments where this doesn't happen, but those are non-conforming to the standard.

DHCP.c 0831- attempt to close socket but socket not open

Posted by heinbali01 on September 8, 2016

Glen, thanks, you are totally right. We will change it.

Andrzej points out that it doesn't matter because NULL may be closed. Indeed the public API FreeRTOS_closesocket() has this check:

~~~~ if( ( xSocket == NULL ) || ( xSocket == FREERTOSINVALIDSOCKET ) ) { xResult = 0; } ~~~~

However, we recently made a change in FreeRTOS_DHCP.c to use vSocketClose(). That's the internal version of FreeRTOS_closesocket(). The internal version does not check for NULL or FREERTOS_INVALID_SOCKET (~0U).

I agree with Richard Damon that the xDHCPData will be zero'd after start-up, but if FreeRTOS_socket() fails, the socket pointer could become FREERTOS_INVALID_SOCKET.

The function prvCreateDHCPSocket() still has an assert:


that we better clean up now.

Please find attached a new version of FreeRTOS_dhcp.c without the configASSERT().


FreeRTOS_DHCP.c (36393 bytes)

DHCP.c 0831- attempt to close socket but socket not open

Posted by heinbali01 on September 9, 2016

A note about the new FreeRTOS_DHCP.c in the previous post: you need the latest Labs release to be able to compile it. In fact the current 160908 release already contains the above FreeRTOS_DHCP.c.

The naming of the DHCP-hook and some enums have changed since the earlier 160112 release. The essence is still the same though.

See here for a detailed description.

The DHCP-hook define has changed:


When the old define is still in seen, an #error will be issued.

Some types and values have changed:


And finally the hook has changed:

BaseType_t xApplicationDHCPUserHook( eDHCPCallbackQuestion_t eQuestion,
    uint32_t ulIPAddress, uint32_t ulNetMask );
eDHCPCallbackAnswer_t xApplicationDHCPHook( eDHCPCallbackPhase_t eDHCPPhase,
    uint32_t ulIPAddress );

The parameter ulNetMask was dropped. It can be retrieved by calling FreeRTOS_GetAddressConfiguration().

Sorry for this inconvenience. In the 160112 release, the DHCP hook was still a new experimental feature. It worked OK but the naming was not very clear. We think that it will be more clear now to new users what the hook does and how it works.

DHCP.c 0831- attempt to close socket but socket not open

Posted by glenenglish on September 10, 2016

Hi Hein , Andrzej and Richard

thanks for all the responses and work you have done.

I have not found any other problems with 0831 to date. I will download 0908 tomorrow and patch that in. ( I just copy over and do an SVN DIFF) . 0831 is now in a live system...running abt 900 pps and 80% utilization of the F4 in DSP...

I have some fixes for the TFTP server from 0831 latest so I will post that in the forum as some input that tomorrow. I have the tftp server working, loading data into external flash,when booting my xilinx fpga...The tricky bit was that my spi flash shared the spi with the ethernet :-) .....solid as a rock.

best regards

[ Back to the top ]    [ About FreeRTOS ]    [ Privacy ]    [ Sitemap ]    [ ]

Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

Version 10.1.0 of the FreeRTOS kernel is available for immediate download. MIT licensed.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


FreeRTOS and other embedded software careers at AWS.

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers


STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS

Xilinx Microblaze and Zynq partner