ATNEL tech-forum

Re: [Atmega+ENC28J60] - losowo nieprawidłowy TCP checksum

2015-12-08T00:45:47+01:00

OK, dzięki za odpowiedź i łopatologiczne tłumaczenie Nie współdzielę pamięci. Wszystko związane z TCP/IP wykonuje się sekwencyjnie.

Pytanie - dlaczego pomijając checksum czasami gubię segmenty 1000-bajtowe?

Zauważyłem jeszcze jedną ciekawą właściwość: przy włączonej opytamlizacji (-O2), wywala niewłaściwą sumę kontrolną, jeżeli trzymam F5 na klawiaturze.

Natomiast jak wyłącze optymalizację to gubię segmenty i nawet ponowienie transmisji i 3-way handshake'a nie załatwia sprawy.

Gubię dane?

Statystyki: Napisane przez PioDer — 8 gru 2015, o 00:45

Re: [Atmega+ENC28J60] - losowo nieprawidłowy TCP checksum

2015-12-08T00:40:07+01:00

Najkrócej jak się da i na przykładzie i dla AVR:

Załóżmy że 2 wątki (np. przerwanie i program główny) mają dostęp do 16-bitowego licznika. Jeden go inkrementuje a drugi dekrementuje. Każdy dostęp do licznika to kilka instrukcji (co najmniej 2 lub więcej tu przyjmę dla jasności że 2). Zakładam dla przykładu że w liczniku jest teraz 0x00FF (czyli 256).

I teraz:
Jeden z wątków zwiększa licznik więc w młodszym bajcie będzie chciał umieścić 0x00 a w starszym 0x01 czyli wynik wg. niego wynikiem to będzie 0x0100.
Drugi wątek będzie chciał licznik zmniejszyć czyli w młodszym bajcie będzie chciał umieścić 0xFE a w starszym 0x00. Wynik dla niego to będzie 0x00FE.

Pomyśl teraz że każdy taki dostęp to co najmniej 2 instrukcje które mogą się "przeplatać" w dowolnej kolejności. Jeśli tak to potencjalnym wynikiem w zależności od kolejności instrukcji asemblerowych będą:
0x0100
0x01FF
0x01FE
0x00FE
0x01FE

Oczywiście nie wszystkie przypadki wystąpią bo w obydwu "wątkach" kolejność dostępu będzie taka sama, ale sam problem wystąpi zawsze "na granicy" dostępów do 2 bajtów licznika. Będzie więc występował z prawdopodobieństwem: 1 / 65536

Mam nadzieję że teraz jasne A jak uniknąć problemu ? Najłatwiej nie współdzielić danych. A jak (niestety) trzeba, to wykonać operację atomowo czyli niepodzielnie czyli... zablokować jeden z "wątków" np. przerwanie (ATOMIC_BLOCK podpowiem).

Statystyki: Napisane przez florekSi — 8 gru 2015, o 00:40

Re: [Atmega+ENC28J60] - losowo nieprawidłowy TCP checksum

2015-12-08T00:21:09+01:00

Fakt, możecie mnie zjechać teraz, że mam obsługę stosu w przerwaniu. Chociaż jeżeli wrzucę netstackService(); do pętli głównej to też potrafi namieszać i psuć sumę kontrolną. Natomiast podaję jeszcze obsługę dzielenia danych i wysyłania segmentów:
[syntax=c]void tcpSendData(tcpip_hdr* packet, uint8_t* data, unsigned int data_len, uint32_t ackno_offset, uint32_t seqno_offset)
{
uint8_t *segment;
uint32_t segment_size;
uint16_t part_len=0;
uint32_t offset=0;
//ograniczam wielkość danych segmentu do TCP_MAX_DATA_LEN

//zastosuję też technikę alokacji pamięci dla nagłówków IP i Ethernet, żeby potem
//ich już nie kopiować i niepotrzebnie alokować kolejną strukturę
if (data_len > TCP_MAX_DATA_LEN)
segment_size = sizeof(struct netTcpHeader) + sizeof(struct netEthIpHeader) +TCP_MAX_DATA_LEN;
else
segment_size = sizeof(struct netTcpHeader) + sizeof(struct netEthIpHeader) + data_len;

segment = malloc(segment_size);
segment += sizeof(struct netEthIpHeader); //przesuwam wskaźnik za nagłówki Ethernet i IP

struct netTcpHeader *hdr = (struct netTcpHeader *)segment;

//wypełnienie nowego nagłówka TCP
hdr->srcport = packet->tcp.destport;
hdr->destport = packet->tcp.srcport;
hdr->seqno = htonl(htonl(packet->tcp.ackno)+seqno_offset);
hdr->len_offset = 5<<4;
hdr->flags = TCP_FLAGS_PSH|TCP_FLAGS_ACK;
hdr->wnd = packet->tcp.wnd;
hdr->ackno = htonl(htonl(packet->tcp.seqno) + ackno_offset);
hdr->urgp = 0x00;

do
{
hdr->tcpchksum = 0x00;
//jeżeli transmitujemy kolejny pakiet, ACKnew=ACK+part_len+1 (za ACK klienta)
if (part_len>0)
hdr->seqno = htonl(htonl(hdr->seqno) + part_len);

part_len = (data_len-offset>TCP_MAX_DATA_LEN) ? TCP_MAX_DATA_LEN : data_len-offset; // długość partu (może być tylko jeden)
offset += part_len;

segment += sizeof(struct netTcpHeader); //przesuwamy wskaźnik dla danych
memcpy(segment, data, part_len);
segment -= sizeof(struct netTcpHeader); //wracamy!

hdr->tcpchksum = tcpChecksum(&packet->ip.srcipaddr, segment, part_len+TCP_HEADER_LEN);

data += part_len;// przesuwam wskaźnik troszkę dalej...

ipSend(HTONL(packet->ip.srcipaddr), IP_PROTO_TCP, part_len+sizeof(struct netTcpHeader), segment - sizeof(struct netEthIpHeader), 1);
}
while(offset
segment -= sizeof(struct netEthIpHeader);
free(segment);
}[/syntax]

Nikt się nie odwołuje do ipGetConfig, jeżeli nawet (ARP) to bez zmiany wartości. Zmienna strukturalna netPseudoIpHeader jest niedostępna z zewnątrz procedury liczenia sumy kontrolnej.

florekSi napisał(a):

Dane w AVR są 8-bitowe i 8-bitowe dostępy są atomowe czyli niepodzielne. Jeśli ktoś/coś odwołuje się do 16-bitów, to masz poprawkę w starszym bajcie i jej brak (albo nieprawidłową) w młodszym (stąd "skok o 0x0100").

Mógłbyś mi to bardziej wyjaśnić/przybliżyć?

BTW. czasami gubię segmenty - tutaj też pytanie, dlaczego?

Pozdrawiam

Statystyki: Napisane przez PioDer — 8 gru 2015, o 00:21

Re: [Atmega+ENC28J60] - losowo nieprawidłowy TCP checksum

2015-12-07T23:47:15+01:00

Błąd sugeruje że masz dostęp do danych z co najmniej 2 miejsc lub co najmniej z 2 wątków (wątkiem może być przerwanie). Dane w AVR są 8-bitowe i 8-bitowe dostępy są atomowe czyli niepodzielne. Jeśli ktoś/coś odwołuje się do 16-bitów, to masz poprawkę w starszym bajcie i jej brak (albo nieprawidłową) w młodszym (stąd "skok o 0x0100").

Czy w międzyczasie (gdy wykonujesz funkcję tcpChecksum), nikt nie odwołuje się do struct netPseudoIpHeader może gdzieś w ipGetConfig()->ip ? Bo tylko to w tym małym fragmencie może sugerować ew. problem.

Ogólnie za mało kodu podałeś by mieć pewność.

Statystyki: Napisane przez florekSi — 7 gru 2015, o 23:47

Re: [Atmega+ENC28J60] - losowo nieprawidłowy TCP checksum

2015-12-07T19:54:30+01:00

Ewidetnie przydałby się AVR Dragon, no, ale niestety go nie mam i muszę radzić sobie "na piechotę"
Analizuję od dłuższego czasu kod i tak: suma kontrolna jest liczona w Big Endian, natomiast w Wiresharku pokazuje mi w Little Endian. Przykład:
jeżeli w Wiresharku suma kontrolna 0xF8FF (poprawna 0xF7FF) w Little Endian to w Big Endian (podczas liczenia) suma kontrolna to 0xFFF8 (a powinna być 0xFFF7).

Oznacza to jedno. Skąd się bierze 0x0001 podczas liczenia sumy kontrolnej ?

Myślałem, że podczas wysyłania PSH ACK coś się chrzani, ale jak robię SYN ACK na strukturze bufora danych wejściowych to też potrafi zawyżyć mi checksum o właśnie 0x0001.

Nie pokazałem jeszcze, że to nie jest za dużo w sumie kontrolnej, tylko za mało o 1.
Suma kontrolna to dopełnienie do FFFF, więc brakuje 0x0001. Tylko skąd ją wziąć?

Statystyki: Napisane przez PioDer — 7 gru 2015, o 19:54

Re: [Atmega+ENC28J60] - losowo nieprawidłowy TCP checksum

2015-12-05T23:25:52+01:00

Witaj

w zasadzie nie widzę w samej funkcji problemu , wydaje mi się że kłopot nie leży po stronie liczenia, a gdzieś głębiej
trzeba by szerzej zerknąć na problem, np spróbować złapać debugerem moment "złego wyliczenia" .

Statystyki: Napisane przez SunRiver — 5 gru 2015, o 23:25

[Atmega+ENC28J60] - losowo nieprawidłowy TCP checksum

2015-12-05T22:19:15+01:00

Dobry wieczór!
Nazywam się Piotrek, jestem tutaj nowy, dlatego proszę o wyrozumiałość.

Chciałbym opisać swój problem. Buduje serwer HTTP na stacku z Procyon AVRLib. Po odpowiednich modyfikacjach, poprawkach i autorskich zmianach nie mam większych problemów z nim, dodatkowo zaimplementowałem prostą obsługę TCP wraz z dzieleniem bufora na mniejsze segmenty danych.

Losowo, w różnych segmentach, czasami pojawia się nieprawidłowa suma kontrolna. Co ciekawe, zawsze o wartość 0x100 (HEX), czyli 256 dziesiętnie.

Szukam już trochę czasu, jednak to trochę jak szukanie igły w stogu siana. Poniżej przedstawiam listing funkcji liczącej sumę kontrolną TCP (jest to moja modyfikacja funkcji netChecksum uwzględniająca pseudonagłówek). Osobiście mam przeczucie, że funkcja jest dobra, bo w 99% przypadków liczy dobrze, a problem leży gdzie indziej, ale może się mylę.
[syntax=c]uint16_t tcpChecksum(uint32_t dstIp, void *data, uint16_t len)
{
register uint32_t sum = 0;

struct netPseudoIpHeader *hdr = malloc(sizeof(struct netPseudoIpHeader));

uint16_t *x=(uint16_t*) hdr;
uint16_t len2 = IP_PSEUDO_HEADER_LEN;

hdr->srcipaddr = htonl(ipGetConfig()->ip);
hdr->destipaddr = dstIp;
hdr->proto = IP_PROTO_TCP;
hdr->reserved = 0x00;//dla pewności
hdr->len = htons(len);

for (;;) {
if (len2 < 2)
break;

sum += *x++;
len2 -= 2;
}
free(hdr);

for (;;) {
if (len < 2)
break;

sum += *((uint16_t *)data);
data+=2;
len -= 2;
}
if (len)
sum += *(uint8_t *) data;

while ((len = (uint16_t) (sum >> 16)) != 0)
sum = (uint16_t) sum + len;
return (uint16_t) sum ^ 0xFFFF;
}[/syntax]

Z góry dziękuję za wszelkie sugestie!

Pozdrawiam

Statystyki: Napisane przez PioDer — 5 gru 2015, o 22:19