[Click] Using nsclick

[Michael Neufeld]

Hi-
I haven't checked it out in detail, but I'm guessing your problem has to 
do with the way the ns-2 side of nsclick handles address resolution and 
packet encapsulation. The ns-2 side of things is expecting regular 
wireline ethernet encapsulation on the packets it gets from click. Under 
the hood, it has to map the ethernet addresses you're using inside of 
click into the internal node addressing scheme that ns-2 uses so that 
ns-2 can apply its MAC and PHY layer models and deliver packets to the 
correct places. In order to do this, it has to know the encapsulation 
type so it can figure out where the approprate addresses are. If you use 
802.11 packet frames instead of regular ethernet frames it will likely 
get confused. If this is indeed the problem, a quick hack to get you up 
and running would be to add a layer of wireline ethernet encapsulation 
to the 802.11 packets your sending out. The ethernet type shouldn't 
matter, and copying the current hop/next hop 802.11 address fields into 
the source and destination fields of the ethernet packet should be OK. 
Fixing it inside of ns-2 would also be an option, but only if you want 
to get involved in ns-2 internals.

Another reasonable source of information about nsclick would be the 
archives of the old e-mail list (now defunct as far as I know) -- I'm 
not sure if that archive is up on the Colorado website or not. This page:

http://systems.cs.colorado.edu/index.php?id=13

also appears to have a little info on it. I think that nsclick is 
between official maintainers at the moment, though it's possible that 
someone at Colorado will pick it up at some point.

-Mike

Michael Voorhaen wrote:
> Hi Jens,
> 
> Jens Mueller wrote:
> 
>> Hi Michael,
>>
>>  
>>
>>> after
>>>
>>> [$node_(0) entry] loadclick "access-point.nsclick"
>>> [$node_(1) entry] loadclick "station.nsclick"
>>>
>>> add something like:
>>>
>>> for {set i 0} {$i < $nodecount} {incr i} {
>>>   $ns_ at 0.0 "[$node_($i) entry] runclick"
>>> }
>>>
>>> This forces the click node to start, else no click code is executed 
>>> until the first data packet is sent to click.
>>>
>>> I'm pretty sure that this will fix your problem.
>>>   
>>
>>
>> I added your snippet. BTW did you know any other resources for using
>> nsclick despite the ones found on
>> http://systems.cs.colorado.edu/Networking/nsclick/?
> 
> Not really, I managed to learn most of what I know on my own in the last 
> year.
> 
>> Your snippet saves
>> me from attaching Agents and Applications to the ClickNodes, which is
>> quite helpful. But it doesn't solve the problem. I changed the order of
>> nodes:
>>
>> [$node_(0) entry] loadclick "access-point.nsclick"
>> [$node_(1) entry] loadclick "station.nsclick"
>> to
>> [$node_(1) entry] loadclick "access-point.nsclick"
>> [$node_(0) entry] loadclick "station.nsclick"
>>
>> And now the access point won't receive any packets from SimDevice. Do
>> you have a clue about this symptom?
>>  
>>
> I don't see any obvious problems. Perhaps it has something to do with 
> the prism2decap that you are using in the station script and not in the 
> AP script. I'm not that familiar with the wireless extensions.
> 
> Michael
> 
>> Bye,
>> Jens
>> _______________________________________________
>> 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
>