[so2] [Tema 5] stp_packet_type.func nu se apeleaza

Madalina Hristache madalina.hristache at gmail.com
Sun May 15 20:27:06 EEST 2016


Madalina Hristache <madalina.hristache at gmail.com>:
> Razvan Deaconescu via so2 <so2 at cursuri.cs.pub.ro>:
>> Madalina Hristache <madalina.hristache at gmail.com> writes:
>>> Madalina Hristache <madalina.hristache at gmail.com>:
>>>> Razvan Deaconescu via so2 <so2 at cursuri.cs.pub.ro>:
>>>>> Madalina Hristache via so2 <so2 at cursuri.cs.pub.ro> writes:
>>>>>> Salut,
>>>>>>
>>>>>> Am văzut pe listele trecute că trebuie să pui htons(ETH_P_STP) în
>>>>>> .type ca să se apeleze .func, dar nu merge și nu îmi dau seama ce
>>>>>> altceva fac prost de nu se apelează. De curiozitate, ETH_P_STP trebuie
>>>>>> să îl mai folosim și altundeva în cod? Că nu îi văd locul.
>>>>>
>>>>> Nu ar trebui să vreo problemă cu apelarea funcției.
>>>>>
>>>>> Simpla definiție a structurii stp_packet_type și a inițializării celor
>>>>> două câmpuri ale ei (.type și .func) ar trebui să fie OK și să apeleze
>>>>> funcția. Ai apelat dev_add_pack în funcția de inițializare a modulului,
>>>>> da?
>>>>>
>>>>> Vei mai folosi constructul ETH_P_STP în fucția de tipul sendmsg atunci
>>>>> când construiești pachetul pentru a-l trimite.
>>>>
>>>> Da, apelez dev_add_pack în init. Mai lucrez să văd ce are.
>>
>> Iar funcția de recvmsg ai definit-o în structura de tip proto_ops? Poate
>> că nu primești pentru că nu trimiți cum trebuie :-) Poate implementarea
>> recepției este bună dar nu este bună implementarea transmiterii
>>
>>>> Altă chestie. Nu îmi e prea clar... cât spațiu trebuie dat ca al
>>>> doilea parametru la skb_reserve (parametrul hlen)?
>>
>> Cel mai bine folosești macro-ul LL_RESERVED_SPACE, așa cum se întâmplă
>> și în af_packet.c[1].
>>
>>> De asemenea, tot în zona aia, de reserve, dev_hard_header, tot apare
>>> un dev în codul model. Ce e cu el?
>>
>> Păi este o încapsulare a unei interfețe de rețea. Poți obține folosind
>> apelul dev_get_by_index așa cum este indicat și în diferite locuri din
>> af_packet.c.
>
> Bun, mulțumesc, m-am lămurit. E greșită implementarea mea de send din
> cauză că nu îmi e clar fluxul de execuție al operațiilor și ce fac
> diferite funcții pe un sk_buff.
>
> Am de pus un header de STP, unul de Ethernet și datele efective.
>
> 1. Înainte de asta, am de alocat un skb. Funcția de alocare are la
> parametrii 2 și 3 niște lungimi. Nu îmi e clar care sunt în cazul meu.
> Am 4 lungimi cu care lucrez: eth_len, stp_len, tail_len și data_len
> primit de funcția de send. Nu înțeleg cum se mapează pe apel.
>
> 2. După ce aloc skb-ul, trebuie să îl populez. În ce ordine fac asta?
> Datele și headerul de STP le pun cu memcpy, iar headerul Ethernet cu
> dev_hard_header. dev_hard_header are ca ultim parametru lungimea
> datelor?
>
> 3. Am de făcut clar un reserve, dar nu știu dacă fac unul cu eth_len +
> stp_len sau fac 2 pe rând. Nu am înțeles cum funcționează.
>
> Cam atât momentan, poate mai ies din ceață.

După o serie de câteva ore de încercări, _cred_ că m-am mai lămurit un
pic, fiindcă am reușit să construiesc un packet. Am verificat ce se
întâmplă pe acolo și pare bine. Problema e un mare oops când dau
comanda dev_queue_xmit. Sunt ceva cazuri mai generale cunoscute în
care se întâmplă asta?

Mersi frumos,

Mădă


More information about the so2 mailing list