[Click] AnonymizeIPAddr and ethernet headers

[Eddie Kohler]

Hi Brian, sorry for not getting back to you earlier.

It turns out that, simply put, the elements that read packets from a live 
network did not set the MAC header annotation.  If you had used "q->data()" 
instead of "q->ether_header()" it would have worked.  But the right answer is 
for FromDevice to set the MAC header annotation, which it now does!

Thanks for the bug report, keep them coming.
Eddie


Brian Gallaway wrote:
> I am using the ipsumdump program derived from Click to do anonymization 
> and sanitization of VOIP traces.  In the end, I will need to capture 
> traffic from the live network, and write the results to a tcpdump file.  
> The hard parts regarding decoding the VOIP packets and dropping RTP 
> voice data have already been completed.
> 
> I also decided to tackle anonymizing ethernet MAC addresses.  I added 
> the following code to AnonymizeIPAddr::simple_action() :
> 
>        // bdg730 - anonymize ethernet by simply writing the ipaddress
>        //          in place of the MAC address
>        //FIXME: memset and memcpy segfault on live captures
>        click_ether *eth = q->ether_header();
>        memcpy(eth->ether_dhost,&dst,4);
>        memcpy(eth->ether_shost,&src,4);
>        memset(&(eth->ether_dhost[4]),0,2);
>        memset(&(eth->ether_shost[4]),0,2);
> 
> However, as you can tell from the comments, this code only worked
> when I had ipsumdump read an existing tcpdump capture.  Running this
> live on the network causes a segfault.
> 
> The reason for the segfault is that the Packet object 'q' has a null 
> ethernet header.  When capturing from a tcpdump file, this header is 
> present and can be modified.  The modifications will be reflected in 
> the tcpdump file that is written by ipsumdump.  But when capturing from 
> the live network, the header is not available to AnonymizeIPAddr.  Yet 
> the ethernet header will end up being written to the final dump file.
> 
> I am just wondering what the reasons are for the differences in behavior 
> here, and if there is somewhere else in the pipeline that I could 
> safely get at and modify the ethernet header before it is output to 
> disk.
> 
> Thanks,
> Brian.
>