[WizFi360] TCP flow control

Wi-Fi Module WizFi360
1

default setting 으로 UART baudrate 가 115200 bps 로 동작합니다. 그런데 baudrate 와 상관없이 PC 쪽에서 너무 빨리 데이타를 보내면 WizFi 가 멈춰버리는 것으로 보여집니다. TCP flow control 이 잘 되어 있다면 WizFi360 쪽에서 그 속도를 줄일 수 있어야 할 것으로 생각하는데요.

WizFi360 의 TCP flow control 을 신뢰할 수 있는지요?

2

호스트 쪽에서 sleep 없이 보낼 때 오류가 발생합니다. 오류가 발생한 상태에서 상황은 아래와 같습니다.

연결
호스트 ← ethernet → TP-LINK Archer VR1600v ← AIR → WizFi ← UART → board

UART: 115200 bps, 8 data bits, 1 stop bit, no parity, no hardware flow control

호스트 정보:
$ uname -a
Linux tangled 4.14.4 #13 SMP Sat Jul 13 19:23:46 EST 2019 x86_64 Intel(R) Core™ i5-4670K CPU @ 3.40GHz GenuineIntel GNU/Linux

보드쪽 디버깅 메시지 출력 - 이 이후 응답 없음, WizFi360 리셋된 것으로 보임.
INF applications/wifi_test.c[237] received(1) =====> [1]
INF applications/wifi_test.c[237] received(16) =====> [tre4ubq7vL2+v8DB]
INF applications/wifi_test.c[237] received(21) =====> [wsPExcbHyMnKy8zNzs/Q0]
INF applications/wifi_test.c[237] received(22) =====> [dLT1NXW19jZ2tvc3d7f4OH]
INF applications/wifi_test.c[237] received(22) =====> [i4+Tl5ufo6err7O3u7/Dx8]
INF applications/wifi_test.c[237] received(23) =====> [vP09fb3+Pn6+/z9/v8AAQID]
INF applications/wifi_test.c[237] received(22) =====> [BAUGBwgJCgsMDQ4PEBESEx]
INF applications/wifi_test.c[237] received(23) =====> [QVFhcYGRobHB0eHyAhIiMkJ]
INF applications/wifi_test.c[237] received(22) =====> [SYnKCkqKywtLi8wMTIzNDU]
INF applications/wifi_test.c[237] received(23) =====> [2Nzg5Ojs8PT4/QEFCQ0RFRk]
INF applications/wifi_test.c[237] received(22) =====> [dISUpLTE1OT1BRUlNUVVZX]
INF applications/wifi_test.c[237] received(4) =====> [WFl�]
]NF applications/wifi_test.c[237] received(1) =====> [
INF applications/wifi_test.c[237] received(8) =====> [
ready
]

그런데 호스트 쪽에서 netstat 으로 확인했을 때 tcp 커넥션은 끊기지 않음.

$ netstat -ta 결과
tcp 0 32768 www.xxxx.com:8888 192-168-1-107:61700 ESTABLISHED

TCP dump 메시지
15:30:50.670762 IP www.xxxx.com.8888 > 192-168-1-107.yyyy.com.61700: Flags [.], seq 947547:948571, ack 1, win 29200, length 1024
15:30:50.851478 IP 192-168-1-107.yyyy.com.61700 > www.xxxx.com.8888: Flags [.], ack 944475, win 6144, length 0
15:30:50.851504 IP www.xxxx.com.8888 > 192-168-1-107.yyyy.com.61700: Flags [.], seq 948571:950619, ack 1, win 29200, length 2048
15:30:51.032331 IP 192-168-1-107.yyyy.com.61700 > www.xxxx.com.8888: Flags [.], ack 946523, win 6144, length 0
15:30:51.032362 IP www.xxxx.com.8888 > 192-168-1-107.yyyy.com.61700: Flags [P.], seq 950619:951643, ack 1, win 29200, length 1024
15:30:51.213176 IP 192-168-1-107.yyyy.com.61700 > www.xxxx.com.8888: Flags [.], ack 948571, win 6144, length 0
15:30:51.213223 IP www.xxxx.com.8888 > 192-168-1-107.yyyy.com.61700: Flags [.], seq 951643:953691, ack 1, win 29200, length 2048
15:30:51.213235 IP www.xxxx.com.8888 > 192-168-1-107.yyyy.com.61700: Flags [.], seq 953691:954715, ack 1, win 29200, length 1024
15:30:51.394765 IP 192-168-1-107.yyyy.com.61700 > www.xxxx.com.8888: Flags [.], ack 950619, win 6144, length 0
15:30:51.394796 IP www.xxxx.com.8888 > 192-168-1-107.yyyy.com.61700: Flags [.], seq 954715:956763, ack 1, win 29200, length 2048
15:30:51.575171 IP 192-168-1-107.yyyy.com.61700 > www.xxxx.com.8888: Flags [.], ack 952667, win 6144, length 0
15:30:51.575206 IP www.xxxx.com.8888 > 192-168-1-107.yyyy.com.61700: Flags [.], seq 956763:957787, ack 1, win 29200, length 1024
15:30:51.756474 IP 192-168-1-107.yyyy.com.61700 > www.xxxx.com.8888: Flags [.], ack 954715, win 6144, length 0
15:30:51.756504 IP www.xxxx.com.8888 > 192-168-1-107.yyyy.com.61700: Flags [.], seq 957787:959835, ack 1, win 29200, length 2048
15:30:51.756511 IP www.xxxx.com.8888 > 192-168-1-107.yyyy.com.61700: Flags [.], seq 959835:960859, ack 1, win 29200, length 1024
15:30:51.936809 IP 192-168-1-107.yyyy.com.61700 > www.xxxx.com.8888: Flags [.], ack 956763, win 6144, length 0
15:30:51.936840 IP www.xxxx.com.8888 > 192-168-1-107.yyyy.com.61700: Flags [.], seq 960859:962907, ack 1, win 29200, length 2048
15:30:52.117557 IP 192-168-1-107.yyyy.com.61700 > www.xxxx.com.8888: Flags [.], ack 958811, win 6144, length 0
15:30:52.117584 IP www.xxxx.com.8888 > 192-168-1-107.yyyy.com.61700: Flags [.], seq 962907:963931, ack 1, win 29200, length 1024
15:30:52.298477 IP 192-168-1-107.yyyy.com.61700 > www.xxxx.com.8888: Flags [.], ack 960859, win 6144, length 0
15:30:52.298506 IP www.xxxx.com.8888 > 192-168-1-107.yyyy.com.61700: Flags [.], seq 963931:965979, ack 1, win 29200, length 2048
15:30:52.298512 IP www.xxxx.com.8888 > 192-168-1-107.yyyy.com.61700: Flags [P.], seq 965979:967003, ack 1, win 29200, length 1024
15:30:52.479305 IP 192-168-1-107.yyyy.com.61700 > www.xxxx.com.8888: Flags [.], ack 962907, win 6144, length 0
15:30:52.479338 IP www.xxxx.com.8888 > 192-168-1-107.yyyy.com.61700: Flags [.], seq 967003:969051, ack 1, win 29200, length 2048
15:30:52.660174 IP 192-168-1-107.yyyy.com.61700 > www.xxxx.com.8888: Flags [.], ack 964955, win 6144, length 0
15:30:52.660207 IP www.xxxx.com.8888 > 192-168-1-107.yyyy.com.61700: Flags [.], seq 969051:970075, ack 1, win 29200, length 1024
15:30:53.486990 IP www.xxxx.com.8888 > 192-168-1-107.yyyy.com.61700: Flags [.], seq 964955:965979, ack 1, win 29200, length 1024
15:30:55.087012 IP www.xxxx.com.8888 > 192-168-1-107.yyyy.com.61700: Flags [.], seq 964955:965979, ack 1, win 29200, length 1024
15:30:58.287022 IP www.xxxx.com.8888 > 192-168-1-107.yyyy.com.61700: Flags [.], seq 964955:965979, ack 1, win 29200, length 1024
15:31:04.687023 IP www.xxxx.com.8888 > 192-168-1-107.yyyy.com.61700: Flags [.], seq 964955:965979, ack 1, win 29200, length 1024
15:31:17.486996 IP www.xxxx.com.8888 > 192-168-1-107.yyyy.com.61700: Flags [.], seq 964955:965979, ack 1, win 29200, length 1024
15:31:43.087003 IP www.xxxx.com.8888 > 192-168-1-107.yyyy.com.61700: Flags [.], seq 964955:965979, ack 1, win 29200, length 1024

일단 보내는 쪽도 멈춥니다. send() 에서 멈춰서 있습니다.
n = send(sock, buf, tobesent, 0);

send()에서 멈춘 시각: Wed Oct 7 15:50:52 EST 2020
send()에서 리턴한 시각: Wed Oct 7 16:06:51 EST 2020

send()가 리턴한 에러 내용.
errno: 32
send: Broken pipe

3

안녕하세요 위즈네트 입니다.

WizFi360의 UART HW Flow control 테스트 자료는 아래와 같습니다.
http://wizwiki.net/wiki/lib/exe/fetch.php/products:wizfi360:wizfi360ds:wizfi360tp_v120k.pdf

추가로 저희쪽에서 테스트 한 결과,
로컬 환경에서 10k 데이터를 5분동안 계속 보내도 정상 동작하는 것을 확인 하였습니다.

10k_send
10k_send1066×751 485 KB

실제로 WizFi360이 리셋을 하는지 WizFi360의 로그와 한번에 보내신 데이터 양을 알려주시면 추가적으로 테스트가 가능 할 것으로 보입니다.

감사합니다.

4

테스트 코드의 일부입니다.

#define FILE_CHUNK_SIZE 1024 /* 1 KBytes */

size_t netSendN(int sock, uint8_t *buf, size_t size) {
size_t sent;
size_t n;

sent = size;
while(sent > 0) {
    n = send(sock, buf, sent, 0);
    if(n < 0) {
        return -1;
    }

    sent -= n;
    buf += n;
}

return size;

}

static char buffer[2 * FILE_CHUNK_SIZE];
static char fbuff[2 * FILE_CHUNK_SIZE];

/* keep running as long as the client keeps the connection open */
while(1) {
    for(n=0; n<FILE_CHUNK_SIZE; n++) {
        fbuff[n] = n % 256;
    }

    tobesent = base64_encode(fbuff, n, buffer); /* ~ 1024 * 4 / 3 */

    buffer[tobesent] = '\n';
    buffer[tobesent+1] = '\r';
    ret = netSendN(sock, buffer, tobesent + 2);
    if(ret < 0) return ret;
}
5

추가로 TCP flow control 테스트를 진행해주신 것에 대해 감사드립니다.

TCP flow control 과 그와 관련한 문제는 없는 것으로 받아들이겠습니다.

Kyle