Hi Parminder,

I don't understand why you need to close both the client and server endpoints if you still want to use it. It should be fine for you to close just the TCP Client endpoint to end a connection and in a case which you want to still use the Server endpoint on the same port, you can leave it be.
Could you clarify your current approach?

In the meantime, I will also try to check if we can help you to get your initial idea working with BGScript on WGM110 but as I said you can work around this issue.

Regards,
Adam

Hi adgoreck, 

Thanks for the workaround.

What I have reported above is a simple example to reproduce the problem.

To avoid anyone being able to connect to the server, I prefer to close the endpoint when it is no longer needed. I prefer to keep the server open only for the necessary period.

Also I prefer to delete the server endpoint so that I have one more endpoint to use it for other purposes.

Regards,

Parminder

Hi Parminder,

Okay, that's reasonable and for that purpose you should be fine to use the same script but you would need to increase the duration value in the Timers. I ran a few tests with different values and the server easily started correctly once again. It should not be a big deal in the use case you've briefly described.

Generally, I can see that you are using those timers quite a lot in your test scripts and that's not really the approach which BGScript was meant to be. It would be better for you to call each next command after you receive appropriate events correlated with previous ones.

Regards,
Adam

Hi Adam,

I have encountered other cases where this problem occurs, in the following example I call each next command after I receive appropriate events correlated with previous ones, but when after 30 seconds I try to start the TCP server, the WGM110 tells me that the server is already started (Address in use). The problem occurs even if I increase the time to 5 minutes.

const UART_ENDPOINT = 0
dim api_result
dim tcp_client_endpoint
dim tcp_server_endpoint

event system_boot(hw, bootloader_version, major, minor, build, revision_len, revision_data)
	call sme_wifi_on()
end

event sme_wifi_is_on(result)
	call sme_set_password(8, "password")
	call sme_connect_ssid(4, "ssid")
end

event sme_wifi_is_off(result)
	call hardware_set_soft_timer(30000, 0, 1) #Switch on wifi every 30 seconds
end

event sme_interface_status(hw_interface, status)
	if(status = 1)
		call tcpip_start_tcp_server(6000, -1)(api_result, tcp_server_endpoint) #Second time it doesn't work
		call endpoint_send(UART_ENDPOINT, 38, "Waiting for a data on port TCP/6000...")
	end if
end

event tcpip_endpoint_status(endpoint, local_ip, local_port, remote_ip, remote_port)
	if(local_port = 6000 && endpoint != tcp_server_endpoint) #new tcp client connected
		tcp_client_endpoint = endpoint
	end if
end

event endpoint_data(endpoint, data_len, data_data)
	if(endpoint = tcp_client_endpoint)
		call endpoint_close(tcp_client_endpoint)
	end if
end

event hardware_soft_timer(handle)
	if(handle = 0)
		call sme_wifi_on()
	end if
end

event endpoint_status(endpoint, type, streaming, destination, active)
	if(endpoint = tcp_client_endpoint && type = endpoint_type_free) #TCP client endpoint closed
		call endpoint_close(tcp_server_endpoint)
	end if
	
	if(endpoint = tcp_server_endpoint && type = endpoint_type_free)	#TCP server endpoint closed
		call sme_disconnect() #Disconnect from Access Point
	end if
end

event sme_disconnected(reason, hw_interface)
	call sme_wifi_off()
end

As a client I used Packet Sender (packetsender.com) on Windows 10, see the video for clarifications.

The strange thing is that this problem occurs only with the most recent and performing routers (AP) and only if PC is connected to the access point via LAN cable, if the PC is connected via WiFi this problem does not occur.

I have encountered this problem with the following routers:

• Asus RT-AC87U (https://www.asus.com/it/Networking/RTAC87U/)
• Netgear R7000 (https://www.netgear.it/home/products/networking/wifi-routers/r7000.aspx)

This is a short video of the problem I encountered with the above code: https://youtu.be/PCrxIFMCbrU

If you want to reproduce this problem in any condition and with any Access Point you can do it by slightly modifying the previous example:

const UART_ENDPOINT = 0
dim api_result
dim tcp_client_endpoint
dim tcp_server_endpoint

event system_boot(hw, bootloader_version, major, minor, build, revision_len, revision_data)
	call sme_wifi_on()
end

event sme_wifi_is_on(result)
	call sme_set_password(8, "password")
	call sme_connect_ssid(4, "ssid")
end

event sme_wifi_is_off(result)
	call hardware_set_soft_timer(30000, 0, 1) #Switch on wifi every 30 seconds
end

event sme_interface_status(hw_interface, status)
	if(status = 1)
		call tcpip_start_tcp_server(6000, -1)(api_result, tcp_server_endpoint) #Second time it doesn't work
		call endpoint_send(UART_ENDPOINT, 38, "Waiting for a data on port TCP/6000...")
	end if
end

event tcpip_endpoint_status(endpoint, local_ip, local_port, remote_ip, remote_port)
	if(local_port = 6000 && endpoint != tcp_server_endpoint) #new tcp client connected
		tcp_client_endpoint = endpoint
	end if
end

event endpoint_data(endpoint, data_len, data_data)
	if(endpoint = tcp_client_endpoint)
		call endpoint_close(tcp_client_endpoint)
		call endpoint_close(tcp_server_endpoint)
		call hardware_set_soft_timer(100, 1, 1)
	end if
end

event hardware_soft_timer(handle)
	if(handle = 0)
		call sme_wifi_on()
	end if
	
	if(handle = 1)
		call sme_disconnect() #Disconnect from Access Point
	end if
end

event sme_disconnected(reason, hw_interface)
	call sme_wifi_off()
end

Regards,

Parminder

Hi,

That's strange I've reproduced this also with one of our routers at the office and passed it on to R&D for further checking. Will let you know the progress.

Regards,
Adam

Hi,

I've received a response from our R&D team. They investigated the reasons for the issue you have encountered and the only solution to what you have encountered is to add more of a delay between the endpoint closure and disconnection from the AP. It is estimated that the minimum for that should be 4 seconds but we would recommend for it to be a little bit more like 5,5-6 seconds to make it more reliable. (For example you can use: call hardware_set_soft_timer(6000, 1, 1)) You should also check that also in your environment to make sure that it would fit to your case. 

Unfortunately they are not able to improve the performance at this particular point as it is due to very low level processes which are necessary to run in the module. Interfering could break the core concept of the implementation. We're sorry about that.

Regards,
Adam

OK thanks for the workaround.

Regards,

Parminder