Jump to content

    
Sign in to follow this  
kan35

lwIP (PPP) проблема

Recommended Posts

а большие пакеты принимать пробовали?

скажем, от 100кб

 

Пакет 100кб ?!

 

Расматриваю приходящие даные как поток с последующей разборкой того что пришло.

Для теста всял большой текстовый файл 250кб и отправил с сервера через инет клиенту (своей железке)

минут 5 может больше приходили данные неприрывно, пока все не пришло, система живет.

 

У Вас значение TCP_MSS = 1500-40, зачем такое значение ?

и почему ?

Какой у Вас размер буфера для принятых данных из модема ?

 

Share this post


Link to post
Share on other sites

Я начал работать на аппноте от ST - там был ethernet и это (1500-40) - максимальный пакет для eth. В принципе, в PPP получается примерно такой же размер - 1260-1460 байт и я его не стал менять. Я пробовал уменьшать до 600 и до 100 байт как я писал в одном из прошлых сообщений- - результат отрицательный.

Буфер приема (PBUF) - 5кБ:

#define PBUF_POOL_SIZE 10

#define PBUF_POOL_BUFSIZE 500

Пробовал увеличивать - не влияет.

Исходники на lwIP скачал с их сайта, и полностью файлы в проекте заменил, чтобы не было шанса что я что то не то сделал...

FreeRTOS обновил до 7.0.2 на всякий случай.

Еще не понятно почему раньше было 9 пакетов - теперь 35... Хотя ничего не изменилось.

Share this post


Link to post
Share on other sites
Еще не понятно почему раньше было 9 пакетов - теперь 35... Хотя ничего не изменилось.

 

Раньше были проблемы с FlowControl, или не всчет !?

 

Какой у Вас размер буфера для принятых данных из модема ?

Подругому: Какой размер очереди queue_gprs_bytes ?

 

#define TCPIP_THREAD_PRIO             (tskIDLE_PRIORITY)
#define PPP_THREAD_PRIO        (tskIDLE_PRIORITY)

 

По приоритетам, не маловато ли ?

 

 

 

Share this post


Link to post
Share on other sites

нет, с FlowControl нет проблем и не было (просто тогда было совпадение).

queue_gprs_bytes сейчас 2000 байт, когда было 200 байт - то иногда не успевал обрабатывать и получались dropped.

Приоритетами играл - не то.

 

Вот еще что, я немного переделал функцию приема и вот что получилось:

void get_rest_of_FW(unsigned long bytesleft, File * file)
{
    LED_RedBlink(10);
    struct netbuf * in_buf;
    unsigned short k = 2;
    while (bytesleft)
    {
        if (in_buf = netconn_recv(conn))
        {
            // успешно приняли что то
            char * incoming_data;
            unsigned long buflen = netbuf_len(in_buf);
            if (incoming_data = (char *)pvPortMalloc(buflen))
            {
                {
                    char * data; u16_t len;
                    netbuf_data(in_buf, (void **)&data, &len);
                    printf_diagn("%d: %lX->%lX (%d:%d)\r\n\r\n", k, data, incoming_data, buflen, bytesleft-buflen );
                }
                netbuf_copy(in_buf, incoming_data, buflen);
                if ( ((signed long)bytesleft - (signed long)buflen) < 0 ) //// заплатка
                    buflen = bytesleft;
                file_write(file, buflen, (unsigned char *)incoming_data);
                vPortFree(incoming_data);
            }
            else
            {
                LED_RedBlink(4);
            }

            bytesleft -= buflen;
            netbuf_delete(in_buf);
            k++;
        }
        else
        {
            //bytesleft = 0;
            netconn_write(conn, "#M#push\r\n", strlen("#M#push\r\n"), NETCONN_NOCOPY); // заплатка
        }
    }
    LED_RedBlink(0);
}

Здесь собственно что: когда данные из модема перестают поступать я кидаю строчку "#M#push\r\n" в сервер (это типа просто текстовое сообщение от клиента), после этого сервер начинает опять слать очередную порцию данных. И так соответственно 2 раза за 130кБ.

В конце массива я на 2 своих текстовых сообщения получаю 2 текстовых ответа-подтверждения (в рамках протокола Wialon). Просто не беру эти куски в учет и все... - файл передан.

В этой связи вопрос такой: может ли быть на сервере или у оператора gsm какое то ограничение на время отправки пакета с таким вот эффектом запора?

Share this post


Link to post
Share on other sites

Проблема решена, оказывается дело не в стеке и даже не в моем софте, а в сервере Wialon который почему то вот так дробил пакеты и зависал. После 2-недельного обвинений меня в том, что у меня кривые руки виалоновские инженеры все таки поправили баг и стало мне счастье.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this