[Click] header annotations, variable meanings, etc.

[Nicholas Murphy]

Ok...I think we were just getting signals crossed in terminology.   
Thanks for clarifying.

Nick

On Dec 10, 2006, at 5:54 PM, Eddie Kohler wrote:

> That is modifying THE PACKET.  The IP header annotation doesn't  
> contain a COPY of the IP header; it contains a POINTER to the ip  
> header.  The IP header data itself is part of the packet data, but  
> the POINTER to the header is an annotation.
>
> Eddie
>
>
> Nicholas Murphy wrote:
>> Hmm...ok.  First of all, I don't see any such element in my  
>> distribution. :)  But I looked at setipdscp.cc (which is maybe  
>> what you were referring to?), and I see the following lines.
>>   uint16_t old_hw = (reinterpret_cast<uint16_t *>(ip))[0];
>>   ip->ip_tos = (ip->ip_tos & 0x3) | _dscp;
>>   uint16_t new_hw = (reinterpret_cast<uint16_t *>(ip))[0];
>>   // 19.Aug.1999 - incrementally update IP checksum according to  
>> RFC1624.
>>   // new_sum = ~(~old_sum + ~old_halfword + new_halfword)
>>   uint32_t sum = (~ip->ip_sum & 0xFFFF) + (~old_hw & 0xFFFF) +  
>> new_hw;
>>   sum = (sum & 0xFFFF) + (sum >> 16);
>>   ip->ip_sum = ~(sum + (sum >> 16));
>> This seems to be modifying the fields I mentioned before that you  
>> said didn't change the original packet.  Will forwarding the  
>> packet with these modifications out on a ToDevice not reflect  
>> these changes?  I'm confused.
>> Sorry for the newbie questions.
>> Thanks,
>> Nick
>> On Dec 10, 2006, at 3:30 PM, Eddie Kohler wrote:
>>> Hi Nick,
>>>
>>> Check out, for example, elements/ip/setipdhcp.cc (the smaction()  
>>> method).
>>>
>>> You need to create a WritablePacket using the uniqueify() method,  
>>> then you can simply modify its data.
>>>
>>>    WritablePacket *wp = p->uniqueify();
>>>    if (!wp)
>>>        // not enough memory to create a new packet
>>>        return 0;
>>>    wp->data()[0] = 'W';  // or whatever
>>>
>>> Eddie
>>>
>>>
>>> Nicholas Murphy wrote:
>>>> Eddie-
>>>> Thanks for your responses.  One quick followup: what is the  
>>>> appropriate way to actually make modifications to the packet if  
>>>> modifying the annotations doesn't actually change the packet?
>>>> Thanks,
>>>> Nick
>>>> On Dec 9, 2006, at 7:09 PM, Eddie Kohler wrote:
>>>>> Hi Nicholas,
>>>>>
>>>>> Nicholas Murphy wrote:
>>>>>> A few random (probably newbie) questions:
>>>>>> 1) So, you seem to need to run packets through something like   
>>>>>> CheckIPHeader in order to fill out the packet header  
>>>>>> annotations,  correct?  Do these annotations persist across  
>>>>>> elements that use  "uniquify", things like Tee, etc.?
>>>>>
>>>>> Yes.
>>>>>
>>>>>> 2) Are transport-layer annotations only filled out once you  
>>>>>> run  through something like IPClassifier?
>>>>>
>>>>> The CheckIPHeader annotation sets both the start-network-header  
>>>>> annotation and the end-network-header==start-transport-header  
>>>>> annotation.
>>>>>
>>>>>> 3) Am I right in thinking that variables like "network_length 
>>>>>> ()"  represent the length from the beginning of the network  
>>>>>> header to the  end of the packet?
>>>>>
>>>>> Yes!
>>>>>
>>>>>> 4) Am I right in assuming there will never be any layering   
>>>>>> information (e.g., ethernet footer) after the data?
>>>>>
>>>>> In practice yes, although this depends on your network layer.
>>>>>
>>>>>
>>>>>> 5) Does changing the annotation variables (e.g., ip_header()- 
>>>>>> >ip_len)  actually modify the packet itself?
>>>>>
>>>>> Nope!
>>>>>
>>>>> Eddie
>>>>>
>>>>>> Hopefully these are all easy yes/no's. :)
>>>>>> Thanks,
>>>>>> Nick
>>>>>> _______________________________________________
>>>>>> click mailing list
>>>>>> click at amsterdam.lcs.mit.edu
>>>>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click