NTP request problem on SPWF04

[DUrbano]

Posted on January 24, 2018 at 14:43

Hi,

I'm working on SPWF04 linked by UART with a NUCLEO F411RE board; I'm facing with a strange problem: I'm trying to connect with an NTP server to synchronize the NUCLEO RTC, so after create a wifi connection, I open the socket, send the data, but the server not answer even if the request going well. This is what I send and what I receive:

TX:  AT+S.SOCKON=193.204.114.105,123,,u

RX: AT-S.On:193.204.114.105:0

RX: AT-S.OK

TX: AT+S.SOCKW=0,48<CR><ESC><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL>

RX: AT-S.OK

but after if I try to check any answer, I read:

TX: AT+S.SOCKQ=0

RX: AT-S.Query:0

RX: AT-S.OK

Please, could anyone tell me what's wrong ? Where's the problem ?

Regards

Davide Urbano

#spwf04 #ntp

[DUrbano]

Posted on January 26, 2018 at 12:00

Thanks a lot Elio for your suggests; if I connect to my local network a PC configured as NTP server, all works perfectly. Even if I try to connect to the TCP port 37 of 

193.204.114.105, I get immediately the 4 bytes...so I'm thinking I have a problem to connect out of my network...

[Elio Cometti]

Posted on January 26, 2018 at 11:18

If <CR> stays for 0x0d, <ESC> 0x1b and <NULL> for 0x00 then the command is formally correct.

As already stated by others contributors, it is quite difficult to capture such packets with wireshark because they are unicast packets (network adapters often ignore unicast packet sent to others host).

I suggest to setup an NTP server (I did a try with this python script

https://github.com/limifly/ntpserver/blob/master/ntpserver.py

 and wireshark on a PC connected to the network the SPWF04S belongs to. This way you can both diagnose your NTP client implementation and verify the SPWF04S actually sends UDP packets to the peer.

Here is the result I get:

On SPWF04S:

AT+S.SOCKON=192.168.1.112,123,,uAT-S.On:192.168.1.112:0AT-S.OKAT+S.SOCKW=0,48AT-S.OK+WIND:55:Pending Data::0:48:48

On (linux) PC:

$ sudo python ntpserver.py local socket:  ('0.0.0.0', 123)Received 1 packetsSended to 192.168.1.135:123It may be not obvious (and it was not for me when I started working with the SPWF04S) that UDP is connectionless and you'll not see any packet sent until you perform the first SOCKW.

Some other hints:

- SPWF04Sx has its own NTP client, you can setup the client (please refer to ip_ntp_* config variables in UM2114) and read the time from the module by AT+S.TIME command or WIND:84 async message.

- 193.204.114.105 has a time server on TCP port 37. As per RFC868, you open a TCP connection to that port and immediately get 4 bytes telling the seconds elapsed since Midnight on January 1st 1900.

[Bogdan Golab]

Posted on January 26, 2018 at 11:56

To monitor foreign traffic we need some preparation. It was easy in hub-era. Nowdays we have switches and virtualization.

Use '

promiscuous

mode' in the Wireshark when you want o capture ALL traffic SEEN by the interface.

It works with hub (as they repeat all traffic on all ports).

Switch needs to copy the traffic from other ports if you want to monitor traffic not destined for your host (port mirror /monitor  feature is required to copy the traffic to the particular interface where the Wireshark is ran on).

When you use 802.q vlan tagging your host needs to recognize vlan tag. This part is tricky. Some network interface can strip the vlan tags and you loose context (the label from the Ethernet frame). Some NIC can leave the van tag and you can see the tag in the Wireshark. Some switches can strip the tag before mirroring the traffic to the monitor port, etc. Some tips are placed on the Wireshark web site.