Re: [ns] new 802.11 - CAP proportion too big

[Mathieu Lacage]

On Wed, 2006-09-06 at 01:02 +0100, Pedro Fortuna wrote:

> "if ((*tmp).second + m_parameters->getMSDULifetime () > now) {"
> 
> It's delay bounded, and its limited with the value returned by
> function getMSDULifetime, which by default is 10 seconds, which is a
> very large value for delay.

Do you have a better suggestion ?

> 
> I've looked at your Yans code and ported the relevant code to your NS2 branch.
> If I may ask, why did you use a queue size limit of 400 packets?

Because this is the max queue size of the linux madwifi driver the last
time I worked on it.

> What is the delay limit on queued packets you implemented on Yans?

10s

Mathieu
-- 

[ns] Does anyone have code of AODV+ETX in ns?

[倪娴]

HI guys:

Does anyone have code of ETX extension on AODV in ns? Thank you!

Re: [ns] new 802.11 - CAP proportion too big

[Pedro Fortuna]

> I cannot remember if the queue is size-bound or delay-bound. My curent
> code (in yans) is both size and delay bound with a default size of 400
> packets. The relevant code is located in mac-queue-80211.cc.
>
> Mathieu
>

"if ((*tmp).second + m_parameters->getMSDULifetime () > now) {"

It's delay bounded, and its limited with the value returned by
function getMSDULifetime, which by default is 10 seconds, which is a
very large value for delay.

I've looked at your Yans code and ported the relevant code to your NS2 branch.
If I may ask, why did you use a queue size limit of 400 packets?
What is the delay limit on queued packets you implemented on Yans?

Thanks.
Best Regards,
Pedro Fortuna

Re: [ns] [bug] tcl-debugger segfaults when printing stack ('w')

[Pedro Vale Estrela]

Hi!
Patch looks, sounds and runs good; similar (correct) code is already in

char **Dbg_ArgcArgv(argc,argv,copy)
... main_argv = alloc = (char **)ckalloc((argc+1)*sizeof(char
*));


>From my initial tests, this has corrected a nasty segmentation fault that
occurred sometimes inside the debugger. 
If you don't already know, I have a modification to enable debugging inside
the TKCon console
http://tagus.inesc-id.pt/~pestrela/ns2/ns2_debugging2.html


I'm forwarding this patch to the ns-developers list
Pedro Vale Estrela

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Christian Walter
> Sent: terça-feira, 5 de Setembro de 2006 17:35
> To: ns-users@ISI.EDU
> Subject: [ns] [bug] tcl-debugger segfaults when printing stack ('w')
> 
> 
> [Bug Report]
> 
> -
> Category:  Run Time - Segmentation Fault
> Package:   other tcl-debug-2.0
> OS:RHEL4/OTHERS
> Environment Variables:
> 
> 
> -
> Description:
> 
> Description of Problem:
> 
> The tcl debugger tcl-debug 2.0 from Don Libes contains a bug in the
> function print_objc (Dbg.c:445) where not enough memory is allocated. The
> variable argv[] should hold an array of char * pointers. The call to
> malloc misses parentheses around objc + 1 and allocates insufficient
> memory.
> A recent GLIBC as well as valgrind detect the error and aborts program
> execution. As a consequence the simulator execution is aborted by the
> system environment.
> 
> How Easily Reproducible: every time
> 
> Steps to Reproduce:
> 1. Start ns2
> 2. Enter 'debug 1'
> 3. Hit s until the stack has at least two elements. starting ns and using
> 's' three or more time is sufficient.
> 3. Simply execute some commands where you should use 'w' multiple times.
> valgrind will immediately detect it. glibc runtime checks sometimes.
> 
> Requirements:
> Ns compiled with --with-debug and tcl-debug. In addition the following
> system components/libraries are of interest:
> 
> Linux: CentOS release 4.4
> GLIBC: glibc-2.3.4-2.25
> valgrind: valgrind-3.1.1-1.EL4
> 
> Actual Results:
> 
> GLIBC:
> dbg2.7> w
>  0: application
> *1: history {add} {s
> }
>  2: llength {add {s
> }}
> dbg2.8> w
> *** glibc detected *** malloc(): memory corruption (fast): 0x08629bf8 ***
> Aborted
> 
> VALGRIND:
> 
> dbg2.6> s
> 2: set len [llength $args]
> dbg2.7> w
>  0: application
> ==12203== Invalid write of size 4
> ==12203==at 0x8242DFB: print_objv (Dbg.c:445)
> ==12203==by 0x8242EB5: PrintStackBelow (Dbg.c:469)
> ==12203==by 0x8242EED: PrintStack (Dbg.c:488)
> ==12203==by 0x82432E5: debugger_trap (Dbg.c:696)
> 
> Expected Results:
> No output
> 
> Additional Information:
> Patch is supplied below:
> --- Dbg.c.orig  2000-08-16 00:09:30.0 +0200
> +++ Dbg.c   2006-09-05 17:05:43.0 +0200
> @@ -440,7 +440,7 @@
>  char **argv;
>  int argc;
>  int len;
> -argv = (char **)ckalloc(objc+1 * sizeof(char *));
> +argv = (char **)ckalloc((objc + 1) * sizeof(char *));
>  for (argc=0 ; argc argv[argc] = Tcl_GetStringFromObj(objv[argc],&len);
>  }
> 
> Kind regards,
>   Christian Walter

Re: [ns] [manet] DYMOUM v0.3 released

[Francisco J. Ros]

Hello,

On Tuesday 05 September 2006 17:46, Dearlove, Christopher (UK) wrote:
> Are the HELLO messages consistent with those defined in NHDP?
>
No, first I want to update all DYMO messages to the packetbb format. Right 
now, HELLOs are like in AODV.

Regards,
fran

> -Original Message-
> From: Francisco J. Ros [mailto:[EMAIL PROTECTED]
> Sent: 01 September 2006 17:02
> To: manet@ietf.org; ns-users@isi.edu
> Cc: [EMAIL PROTECTED]
> Subject: [manet] DYMOUM v0.3 released
>
>*** WARNING ***
>
> This mail has originated outside your organization,
> either from an external partner or the Global Internet.
>  Keep this in mind if you answer this message.
>
> 
>
> We are pleased to announce the release of DYMOUM v0.3, an implementation
> of
> the DYMO routing protocol both for Linux kernels and the ns2 Network
> Simulator. It is freely available under the terms of the General Public
> License (GPL).
>
> This new version adds support for neighborhood monitoring via HELLO
> messages,
> is highly compliant with the latest spec (draft-05) and fixes some
> little
> bugs of the previous release. A detailed list of changes can be seen in
> the
> CHANGELOG file.
>
> We expect the next release to comply with the upcoming draft-06 and to
> support
> the packetbb message format. A detailed list of pending tasks can be
> seen in
> the CHANGELOG file.
>
> DYMOUM Project Website:
>   http://masimum.inf.um.es/?Software:DYMOUM
>
> Download it from Sourceforge.net:
>   http://sourceforge.net/projects/dymoum/
>
> Feedback is welcomed.
>
> Best regards,
> Francisco J. Ros
> Pedro M. Ruiz
>
> ___
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
>
>
>
> 
> This email and any attachments are confidential to the intended
> recipient and may also be privileged. If you are not the intended
> recipient please delete it from your system and notify the sender.
> You should not copy it or use it for any purpose nor disclose or
> distribute its contents to any other person.
> 

[ns] [bug] tcl-debugger segfaults when printing stack ('w')

[Christian Walter]

[Bug Report]

-
Category:  Run Time - Segmentation Fault
Package:   other tcl-debug-2.0
OS:RHEL4/OTHERS
Environment Variables:


-
Description:

Description of Problem:

The tcl debugger tcl-debug 2.0 from Don Libes contains a bug in the function 
print_objc (Dbg.c:445) where not enough memory is allocated. The variable 
argv[] should hold an array of char * pointers. The call to malloc misses 
parentheses around objc + 1 and allocates insufficient memory.
A recent GLIBC as well as valgrind detect the error and aborts program 
execution. As a consequence the simulator execution is aborted by the system 
environment.

How Easily Reproducible: every time

Steps to Reproduce:
1. Start ns2
2. Enter 'debug 1'
3. Hit s until the stack has at least two elements. starting ns and using 's' 
three or more time is sufficient.
3. Simply execute some commands where you should use 'w' multiple times. 
valgrind will immediately detect it. glibc runtime checks sometimes. 

Requirements:
Ns compiled with --with-debug and tcl-debug. In addition the following system 
components/libraries are of interest:

Linux: CentOS release 4.4
GLIBC: glibc-2.3.4-2.25
valgrind: valgrind-3.1.1-1.EL4

Actual Results:

GLIBC:
dbg2.7> w
 0: application
*1: history {add} {s
}
 2: llength {add {s
}}
dbg2.8> w
*** glibc detected *** malloc(): memory corruption (fast): 0x08629bf8 ***
Aborted

VALGRIND:

dbg2.6> s
2: set len [llength $args]
dbg2.7> w
 0: application
==12203== Invalid write of size 4
==12203==at 0x8242DFB: print_objv (Dbg.c:445)
==12203==by 0x8242EB5: PrintStackBelow (Dbg.c:469)
==12203==by 0x8242EED: PrintStack (Dbg.c:488)
==12203==by 0x82432E5: debugger_trap (Dbg.c:696)

Expected Results:
No output

Additional Information:
Patch is supplied below:
--- Dbg.c.orig  2000-08-16 00:09:30.0 +0200
+++ Dbg.c   2006-09-05 17:05:43.0 +0200
@@ -440,7 +440,7 @@
 char **argv;
 int argc;
 int len;
-argv = (char **)ckalloc(objc+1 * sizeof(char *));
+argv = (char **)ckalloc((objc + 1) * sizeof(char *));
 for (argc=0 ; argc

Re: [ns] multiple access points

[Imad Ajarmeh]

hi,
iam trying to simulate a scenario that involves multiple access points to
cover a relatively large area, i want to use different technologies like
802.11a and 802.11g together.
where to start???
can anybody please tell me where to start or where to find help regarding
this...
thanks...


On 9/4/06, Imad Ajarmeh <[EMAIL PROTECTED]> wrote:
>
> hi,
> iam trying to simulate a scenario that involves multiple access points to
> cover a relatively large area, i want to use different technologies like
> 802.11a and 802.11g together.
> where to start???
> can anybody please tell me where to start or where to find help regarding
> this...
> thanks...
>
> --
> Imad Ajarmeh
>



-- 
Imad Ajarmeh

[ns] urgent help...multiple access points [mixed, 802.11a and 802.11g]

[Imad Ajarmeh]

hi,
iam trying to simulate a scenario that involves multiple access points to
cover a relatively large area, i want to use different technologies like
802.11a and 802.11g together.
where to start???
how to mix more than one type of access point.
can anybody please tell me where to start or where to find help regarding
this...
thanks...

-- 
Imad Ajarmeh


-- 
Imad Ajarmeh

Re: [ns] idle/sleep state

[Julian Monteiro]

If you are using the protocol at 'ns-2.29/diffusion' (old), I think you 
can use the commands 'on' and 'off' as it is there.
If you wanna use the 'diffusion3/' protocol, then you should remove  the 
call to 'reset-state' in the command 'off' at mobilenode.cc.

[]s

Super Torresmo wrote:
> So, if I'm using the diffusion protocol, what should I do to turn 
> nodes on and off?
>  
>
>
>  
> On 9/4/06, *Julian Monteiro* <[EMAIL PROTECTED] 
> > wrote:
>
>
> I've misunderstood the results of that grep, I didn't realized that
> these strcmp were the functions... sorry.
> Now I see,  the 'reset-state' command is only used in the directed
> diffusion protocol from C. Intanagonwiwat.
>
> So, if I'm not using diffusion I can remove that line, or implement a
> 'reset-state' in all protocols I want to simulate.
> ... but this is not the time for a patch.
>
> Best regards,
> Julian
> p.s. this is a very good page, thanks! :
> http://tagus.inesc-id.pt/~pestrela/ns2/ns2_debugging3.html
> 
>
> Pedro Vale Estrela wrote:
> >
> >> -Original Message-
> >> From: [EMAIL PROTECTED]
>  [mailto:
> [EMAIL PROTECTED] ] On Behalf
> >> Of Julian Monteiro
> >> Sent: segunda-feira, 4 de Setembro de 2006 15:40
> >> To: Alex Triffitt
> >> Cc: ns-users@ISI.EDU 
> >> Subject: Re: [ns] idle/sleep state
> >>
> >>
> >> Hello Alex,
> >>
> >> I'm not sure if this is the best solution, but you can use the
> 'on' and
> >> 'off' commands in the mobile node to put it to sleep.
> >> Unfortunately these commands doesn't work.in 
> NS2 off the box (as of
> >> version 2.29.3)
> >>
> >> To do so, you need comment out a call to a unexistent tcl
> function in
> >> the line 202 of ns-2.29/common/mobilenode.cc :
> >> // Remove this line. I didn't found this function anywhere!.
> >> // tcl.evalf("%s reset-state", str);
> >>
> >
> > ns2> grep "reset-state" */*.cc
> >
> > this function is defined in diffusion/diffusion.cc , flodding.cc and
> > omni-cast.cc
> >
> >
> >
> >> After that, to put a node to sleep, mix the commands 'on' and
> 'off' in
> >> the scenery model, e.g:
> >> $ns_ at 3.0 "$node_(0) off"
> >> $ns_ at 10.0 "$node_(0) on"
> >>
> >> Also, the Energy Model must be enabled to use that, i.e, put
> above line
> >> in node configuration:
> >> -energyModel EnergyModel
> >>
> >>
> >
> >
> >
> >> Best Regards,
> >> Julian
> >> p.s. How do I submit this patch to the NS2 tree?
> >>
> >
> > An excellent question indeed.
> > Short answer:
> >diff -C3 "original file" "modified file" > idle.patch
> >
> > persons are able to apply your patch using
> >cat idle.patch | patch
> >
> >
> > longer answer:
> >check step 7 of
> > http://tagus.inesc-id.pt/~pestrela/ns2/ns2_debugging3.html
> 
> >
> > if you have more questions please ask; however, please submit
> your patch
> > only after you are sure what is that "reset-state" code about!
> >
> > Pedro Vale Estrela
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >> Alex Triffitt wrote:
> >>
> >>> I am wanting to put a node into a idle/sleeping state where it
> will not
> >>>
> >> listen for transmitted packets and to all intense and purposes
> is not
> >> participating in the MANET i've created. Could someone
> possiblely tell me
> >> how this is done or point out where I can find out how to do this
> >>
> >>> Kindest regardsAlex
> >>>
> >>>
> >
> >
> >
>
>

[ns] increase IP header size in NS

[lekkie omotayo]

Does anybody know ow to increase d header size of an IP packet in ns using
tcl?

I ''l b grateful if anybody can shared dat wit me.

Lekkie.

Re: [ns] idle/sleep state

[Super Torresmo]

So, if I'm using the diffusion protocol, what should I do to turn nodes on
and off?




On 9/4/06, Julian Monteiro <[EMAIL PROTECTED]> wrote:
>
>
> I've misunderstood the results of that grep, I didn't realized that
> these strcmp were the functions... sorry.
> Now I see,  the 'reset-state' command is only used in the directed
> diffusion protocol from C. Intanagonwiwat.
>
> So, if I'm not using diffusion I can remove that line, or implement a
> 'reset-state' in all protocols I want to simulate.
> ... but this is not the time for a patch.
>
> Best regards,
> Julian
> p.s. this is a very good page, thanks! :
> http://tagus.inesc-id.pt/~pestrela/ns2/ns2_debugging3.html
>
> Pedro Vale Estrela wrote:
> >
> >> -Original Message-
> >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf
> >> Of Julian Monteiro
> >> Sent: segunda-feira, 4 de Setembro de 2006 15:40
> >> To: Alex Triffitt
> >> Cc: ns-users@ISI.EDU
> >> Subject: Re: [ns] idle/sleep state
> >>
> >>
> >> Hello Alex,
> >>
> >> I'm not sure if this is the best solution, but you can use the 'on' and
> >> 'off' commands in the mobile node to put it to sleep.
> >> Unfortunately these commands doesn't work.in NS2 off the box (as of
> >> version 2.29.3)
> >>
> >> To do so, you need comment out a call to a unexistent tcl function in
> >> the line 202 of ns-2.29/common/mobilenode.cc :
> >> // Remove this line. I didn't found this function anywhere!.
> >> // tcl.evalf("%s reset-state", str);
> >>
> >
> > ns2> grep "reset-state" */*.cc
> >
> > this function is defined in diffusion/diffusion.cc , flodding.cc and
> > omni-cast.cc
> >
> >
> >
> >> After that, to put a node to sleep, mix the commands 'on' and 'off' in
> >> the scenery model, e.g:
> >> $ns_ at 3.0 "$node_(0) off"
> >> $ns_ at 10.0 "$node_(0) on"
> >>
> >> Also, the Energy Model must be enabled to use that, i.e, put above line
> >> in node configuration:
> >> -energyModel EnergyModel
> >>
> >>
> >
> >
> >
> >> Best Regards,
> >> Julian
> >> p.s. How do I submit this patch to the NS2 tree?
> >>
> >
> > An excellent question indeed.
> > Short answer:
> >diff -C3 "original file" "modified file" > idle.patch
> >
> > persons are able to apply your patch using
> >cat idle.patch | patch
> >
> >
> > longer answer:
> >check step 7 of
> > http://tagus.inesc-id.pt/~pestrela/ns2/ns2_debugging3.html
> >
> > if you have more questions please ask; however, please submit your patch
> > only after you are sure what is that "reset-state" code about!
> >
> > Pedro Vale Estrela
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >> Alex Triffitt wrote:
> >>
> >>> I am wanting to put a node into a idle/sleeping state where it will
> not
> >>>
> >> listen for transmitted packets and to all intense and purposes is not
> >> participating in the MANET i've created. Could someone possiblely tell
> me
> >> how this is done or point out where I can find out how to do this
> >>
> >>> Kindest regardsAlex
> >>>
> >>>
> >
> >
> >
>
>