[Click] can someone please explain how click deals with IP headers?

Eddie Kohler kohler at cs.ucla.edu
Mon Oct 29 11:51:00 EDT 2007


 > It core dumps because it is trying to read IP headers from where
 > Ethernet headers are.  You need to use a classifier first and then strip
 > 14 bytes before you can send packets to the IPClassifier.

Actually this isn't quite right.  IPClassifier requires the "IP header 
annotation".  The annotation tells other elements where the IP header is 
located and how long it is.  Without the annotation you will see crashes, and 
stripping the Ethernet header isn't enough to provide the annotation.  This 
annotation is set by the following elements:

- MarkIPHeader (does not check version, header sanity, or checksum)
- CheckIPHeader (checks version and header sanity and checksum)
- CheckIPHeader2 (checks version and header sanity, doesn't check checksum by 
default)

You probably want CheckIPHeader.  And you probably want to handle only the 
truly IP based packets.

   FromDevice(...) -> Classifier(12/0800  /* Ethernet type for IP */)
                   -> CheckIPHeader(14)
                   -> ...

Thanks Beyers for pointing this out.
Eddie


Roman Chertov wrote:
> Daniel McBrearty wrote:
>> Hi
>>
>> Have been playing around with this great piece of software for a few
>> days. Had some success with it, but one thing seems to cause some
>> trouble.
>>
>> I seem not to be understanding something basic about how many elements
>> handle IP headers.
>>
>> For instance, if I have a config like this :
>>
>> ipc IPClassifier( ip proto udp, - );
>> FromDevice( etho, PROMISC true ) -> ipc;
>> ipc[0] -> Queue() -> ToDevice( eth1 );
>> ipc[1] -> Discard();
>>
>> Now, I run this in user mode, and send it a few hundred RTP packets.
>> It core dumps. The core dump goes if I remove ipc.
> 
> 
> Roman
> 
>> Other problems I have had have been trying to use SetIPAddress(
>> 1.2.3.4, dst ) in such a config, but the ip appears unchanged in
>> wireshark.
>>
>> Do these IP based elements expect the ethernet header to be stripped
>> off, or explicitly told the position relative to the start of an
>> ethernet header? I seem to remember seeing something like this when I
>> started reading the docs ... but I can't find that now.
>>
>> thanks
>>
>> Daniel
>> _______________________________________________
>> click mailing list
>> click at amsterdam.lcs.mit.edu
>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click



More information about the click mailing list