Re: [ns] off_arp_ (fwd)

[Haobo Yu <haoboy@catarina.usc.edu>]

Yes this is a problem. There are a couple of related problems of setting
off_*_ to 0 in tcl file. This should NEVER be done otherwise packet header
will be messed up. 

In fact, accessing headers through off_<hdr>_ is out-of-date. Currently 
the default way is using something like hdr_cmn::offset_ and
hdr_cmn::access(). The packet header section in the ns manual provides
obsolete information about this. 

However, this bug seldom shows its effect since ns packet header is
"sparse", in that much of its space is not used in a single simulation.
Most often it'll result in seg faults in irrelevant places, e.g., crash of
wireless3 of WLtutorial on fbsd. I'll check in a patch to fix them all
today or tomorrow.

Thanks for the report.

- Haobo

> ---------- Forwarded message ----------
> Date: Tue, 15 Aug 2000 12:24:50 -0700
> From: Aman Singla <aman@atheros.com>
> To: NS Users Mailing List <ns-users@ISI.EDU>
> Subject: [ns] off_arp_
> 
> Hi-
> 
> I notice that ns/tcl/lib/ns-mobilenode.tcl does:
> ARPTable set off_arp_         0
> 
> and ns/tcl/lib/ns-cmutrace.tcl does:
> CMUTrace/Drop set off_arp_ 0
> 
> This causes ARPTable::off_arp_ in the compiled
> code to be set to 0 when the bind("off_arp_", &off_arp)
> call is made (instead of 1040 - the value generated
> by PacketHeaderManager in my config). This results in
> the ARP module generating the arp header at offset
> 0 in the packet. The CMUTrace class does pick up the
> right value of off_arp_ into its own protected variable,
> looks for the ARP header at the right place (offset 1040)
> and finds garbage, generating erroneous
> values for ARP packets in the trace file.
> 
> I haven't confirmed if the CMUTrace/Drop class gets
> the right offset for the arp packet or not..
> 
> I'm using a snapshot from the ns Aug 8 code.
> 
> My interpretation of the docs prompted me to comment
> out the above two lines of code in the tcl files, which
> resulted in the correct behavior (i.e. Trace file output
> makes sense).
> 
> So - I'd assume this was a bug.. unless I'm missing
> something (I'm new to ns) - in which case could someone
> please explain the intent of this code and the behavior
> I see in the generated trace.
> 
> thanks,
> 
> :a
>