I believe that bug600 fixes this also

Ok, I just pulled in latest stuff in..

And bug is not exactly fixed (well, can't test yet at least), it simply appears that I no longer have the option of NOT installing GlobalRouting on a node if I use InternetStackHelper to put the IP stack on one - it's always there. So the situation will not even arise.

So, the old way where I could only install Global Routing on some nodes is gone, so I can't bring the bug to manifest in the first place.

Would it be possible to change the Internet Stack Helper constructor - currently taking no parameters - so that there would be an option to choose which routing protocols it will include in the stack? I really don't want to run GlobalRouting on ALL nodes.

Right now the constructor takes no parameters - the parameter could be either a list of routing protocols to be installed (without parameters it should probably default to all), maybe a bitfield that can be ORred?

I could, for real, use helpers e.g. as follows

InternetStackHelper RouterHelper();  // Default, includes every protocol
InternetStackHelper StaticRouter(ROUTING_STATIC);  // Only Static
InternetStackHelper Host(ROUTING_NONE); // Nothing

So the constructor would become

// Default mask has everything enabled
InternetStackHelper::InternetStackHelper (uint32_t rflags=0xffffffff)
{
  SetTcp ("ns3::TcpL4Protocol");
  static Ipv4StaticRoutingHelper staticRouting;
  static Ipv4GlobalRoutingHelper globalRouting;
  static Ipv4ListRoutingHelper listRouting;
  if (rflags&ROUTING_STATIC) { listRouting.Add (staticRouting, 0); }
  if (rflags&ROUTING_GLOBAL) { listRouting.Add (globalRouting, -10); }
  SetRoutingHelper (listRouting);
}

(And somewhere we have these macros defined)

and then install as I want...and this can then be scaled to other protocols, e.g. InternetStackHelper OlsrNodeHelper(ROUTING_OLSR);)

The reason is that I don't want to make certain routers becoming transits - I want to filter routes, and easiest way to do that for me right now is not install a dynamic (or semi-dynamic in case of global) protocol on such a node at all, yet I want to use dynamic stuff elsewhere in simulation. 

Also, I'm in the process of adding Inject/Redistribution support to GlobalRouting (in fact, I ran into the original while writing code for that) so that external routes could propagate through the cloud, so suddendly having to deal with GlobalRouting on all nodes puts a dent in there (see http://groups.google.com/group/ns-3-users/browse_thread/thread/fe10285f3c77f047).

Anyway, if this idea of InternetStackHelper with a requestable list of routing protocols to be installed is acceptable, I can submit a patch. And then continue dealing with original issue...

(In reply to comment #2)
> Ok, I just pulled in latest stuff in..
> 
> And bug is not exactly fixed (well, can't test yet at least), it simply appears
> that I no longer have the option of NOT installing GlobalRouting on a node if I
> use InternetStackHelper to put the IP stack on one - it's always there. So the
> situation will not even arise.

Here is how I believe the current API will let you do this:

  NodeContainer cWithGlobal;
  NodeContainer cWithoutGlobal;

  InternetStackHelper internet;
  internet.Install (cWithGlobal);  // Installs the default configuration
  
  Ipv4ListRoutingHelper list;
  list.Add (staticRouting, 0);
  list.Add (olsr, 10);
  internet.SetRoutingHelper (list);  // overwrites previous routing helper
  internet.Install (cWithoutGlobal);


> 
> Also, I'm in the process of adding Inject/Redistribution support to
> GlobalRouting (in fact, I ran into the original while writing code for that) so
> that external routes could propagate through the cloud, so suddendly having to
> deal with GlobalRouting on all nodes puts a dent in there (see
> http://groups.google.com/group/ns-3-users/browse_thread/thread/fe10285f3c77f047).
> 

do you have a sketch of how the API might look when you are done with the static redistribution patch?

(In reply to comment #3)
> do you have a sketch of how the API might look when you are done with the
> static redistribution patch?

  Right now it seems that I'd be adding two public methods to ipv4-global-routing.h, basically 
Inject(Ipv4Address, Ipv4Mask) which simply saves to an std::list <Ipv4RoutingTableEntry *> what you want to inject, and GetInjectedRoutes, which returns a copy of that list. 

I also need additional helper function GetGlobalRouting which is basically copy-pasted from the similar one in ipv4-static-routing.h to get a pointer to the routing object.

  Internally, I'm making some changes to DiscoverLSAs so that it grabs that list and inserts them as Type 5 LSA's. 

  Anyway, will test with your suggestion whether the original bug still exist...thanks for the tip. 

Ok, this truly seems to be fixed now.