<div dir="ltr">2013/5/14 Vlad Dogaru <span dir="ltr"><<a href="mailto:ddvlad@herebedragons.ro" target="_blank">ddvlad@herebedragons.ro</a>></span><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div class="im">On Tue, May 14, 2013 at 01:45:21PM +0300, Dan Filimon wrote:<br>
> Un ultim lucru, dimensiunea header-ului Ethernet o pun 14 octeți și ignor<br>
> strategic trailer-ul?<br>
> Sau, fac ca în af_packet și iau headerul cu LL_RESERVED_SPACE și trailerul<br>
> cu dev->needed_tailroom.<br>
<br>
</div>Varianta a doua sună mai bine.  Tailroom-ul oricum nu e nevoie să îl iei<br>
în calcul decât la alocarea skb-ului.<br></blockquote><div><br></div><div style>Am făcut așa și observ că LL_RESERVED_SPACE întoarce 16 octeți dar după ce scriu efectiv offset-ul întors de dev_hard_header e 14 octeți.</div>

<div style>N-ar fi asta o tragedie, dar acum, deși testul îmi trece, aș vrea să afișez mesajul copiat. Am făcut:</div><div style>printk(KERN_ALERT "%s\n", skb->data + ehlen + shlen); </div><div style><br></div>

<div style>Unde ehlen e lungimea headerului Ethernet (14 octeți) și shlen e lungimea header-ului STP (8 octeți). Dar, asta-mi afișează garbage.</div><div style>De ce? Doar nu poate fi o chestie de endianness, fiindcă ăștia sunt octeți.</div>

</div></div></div>