diff --git a/doc/manual/callbacks.texi b/doc/manual/callbacks.texi
index b355ee0b4..a68a89a3b 100644
--- a/doc/manual/callbacks.texi
+++ b/doc/manual/callbacks.texi
@@ -251,7 +251,7 @@ The caller defines a specific part of the functor that really is just there to
 implement the specific operator() method,
 
 @verbatim
-  template <typname T, typename ARG>
+  template <typename T, typename ARG>
   class SpecificFunctor : public Functor
    {
    public:
@@ -305,7 +305,7 @@ case, provides the integer argument:
   void 
   LibraryFunction (Functor functor)
   {
-    // Ececute the library function
+    // Execute the library function
     functor(1234);
   }
 @end verbatim
@@ -362,7 +362,7 @@ Consider also the following main program snippet:
 @end verbatim
 
 This is an example of a C-style callback -- one which does not include or need
-a @code{this} pointer.  The function template @code{Callback} is esentially the
+a @code{this} pointer.  The function template @code{Callback} is essentially the
 declaration of the variable containing the pointer-to-function.  In the example
 above, we explicitly showed a pointer to a function that returned an integer and
 took a single integer as a parameter,  The @code{Callback} template function is
@@ -551,7 +551,7 @@ bound arguments.  Conceptually, it extends the specific functor described above
 with one or more bound arguments
 
 @verbatim
-  template <typname T, typename ARG, typename BOUND_ARG>
+  template <typename T, typename ARG, typename BOUND_ARG>
   class SpecificFunctor : public Functor
    {
    public:
@@ -581,7 +581,7 @@ the single parameter, as in
   m_promiscSnifferTrace (m_currentPkt);
 @end verbatim
 
-the imlpementation of @code{operator()} adds the bound parameter into the actual
+the implementation of @code{operator()} adds the bound parameter into the actual
 function call:
 
 @verbatim
diff --git a/doc/manual/csma.texi b/doc/manual/csma.texi
index 8bd162aab..8577bd625 100644
--- a/doc/manual/csma.texi
+++ b/doc/manual/csma.texi
@@ -218,7 +218,7 @@ attempted.  The default maximum number of retries is 1000.
 @section Using the CsmaNetDevice
 
 The CSMA net devices and channels are typically created and configured using
-the associated @code{CsmaHelper} object.  The various ns3 device dhelpers 
+the associated @code{CsmaHelper} object.  The various ns3 device helpers 
 generally work in a similar way, and their use is seen in many of our example
 programs.
 
diff --git a/doc/manual/distributed.texi b/doc/manual/distributed.texi
index 8cbe3539f..801e19ffd 100644
--- a/doc/manual/distributed.texi
+++ b/doc/manual/distributed.texi
@@ -106,7 +106,7 @@ these steps could be followed to resolve the conflict:
 Also, it may be necessary to add the openmpi bin directory to PATH in order to 
 execute mpic++ and mpirun from the command line.  Alternatively, the full path 
 to these executables can be used.  Finally, if openmpi complains about the 
-inablility to open shared libraries, such as libmpi_cxx.so.0, it may be 
+inability to open shared libraries, such as libmpi_cxx.so.0, it may be 
 necessary to add the openmpi lib directory to LD_LIBRARY_PATH.
 
 @subsection Building and Running Examples
diff --git a/doc/manual/emulation.texi b/doc/manual/emulation.texi
index f551f6897..57d798e06 100644
--- a/doc/manual/emulation.texi
+++ b/doc/manual/emulation.texi
@@ -39,7 +39,7 @@ the ns-3 tracing, logging, visualization and statistics gathering tools.
 In what can be viewed as essentially an inverse configuration, we allow ``real'' 
 machines running native applications and protocol stacks to integrate with
 an ns-3 simulation.  This allows for the simulation of large networks connected
-to a real mahince, and also enables virtualization.  A simulation of this kind
+to a real machine, and also enables virtualization.  A simulation of this kind
 is shown in the following figure:
 
 @float Figure,fig:emulated-channel
diff --git a/doc/manual/other.texi b/doc/manual/other.texi
index 22d6b0622..346caa430 100644
--- a/doc/manual/other.texi
+++ b/doc/manual/other.texi
@@ -901,7 +901,7 @@ after this initialization.  They are:
     Ipv4AddressGenerator::SeedAddress (mask, baseAddress);
 @end verbatim
 
-We provide an IP address generator class to allow us to programatically 
+We provide an IP address generator class to allow us to programmatically
 allocate IP addresses.  The first call to @code{SeedNetwork} gives the
 address generator a starting network number to use when generating addresses.
 The second call to @code{SeedAddress} gives the address generator a starting
@@ -1011,7 +1011,7 @@ relatively abstract bus class, we can create bus networks with 4, 40 or 4000
 nodes with no additional effort.
 
 A use of the bus network class is shown in the file 
-@code{bus-netowrk.cc} located in the @code{tutorial} directory.  The
+@code{bus-network.cc} located in the @code{tutorial} directory.  The
 interesting code is,
 
 @verbatim
diff --git a/doc/manual/tracing.texi b/doc/manual/tracing.texi
index 449f3d1b0..ba37a3977 100644
--- a/doc/manual/tracing.texi
+++ b/doc/manual/tracing.texi
@@ -367,7 +367,7 @@ of specifying which traces should be enabled through a node, device pair.  For
 example, you may want to specify that pcap tracing should be enabled on a 
 particular device on a specific node.  This follows from the @code{ns-3} device
 conceptual model, and also the conceptual models of the various device helpers.
-Following naturallyu from this, the files created follow a 
+Following naturally from this, the files created follow a 
 <prefix>-<node>-<device> naming convention.  
 
 Protocol helpers look at the problem of specifying which traces should be
@@ -435,7 +435,7 @@ implements @code{EnablePcapInternal} correctly.
 
 @verbatim
   void EnablePcap (std::string prefix, Ptr<NetDevice> nd, bool promiscuous = false, bool explicitFilename = false);
-  void EnablePcap (std::string prefix, std::string ndName, bool promiscuous = false, bool explicitFilenaqme = false);
+  void EnablePcap (std::string prefix, std::string ndName, bool promiscuous = false, bool explicitFilename = false);
   void EnablePcap (std::string prefix, NetDeviceContainer d, bool promiscuous = false);
   void EnablePcap (std::string prefix, NodeContainer n, bool promiscuous = false);
   void EnablePcap (std::string prefix, uint32_t nodeid, uint32_t deviceid, bool promiscuous = false);
@@ -550,7 +550,7 @@ Finally, two of the methods shown above,
 
 @verbatim
   void EnablePcap (std::string prefix, Ptr<NetDevice> nd, bool promiscuous = false, bool explicitFilename = false);
-  void EnablePcap (std::string prefix, std::string ndName, bool promiscuous = false, bool explicitFilenaqme = false);
+  void EnablePcap (std::string prefix, std::string ndName, bool promiscuous = false, bool explicitFilename = false);
 @end verbatim
 
 have a default parameter called @code{explicitFilename}.  When set to true,
@@ -930,7 +930,7 @@ taken for devices in the @code{ns-3} system are of the form
 there is a one-to-one correspondence between protocols and @code{Nodes}.
 This is because protocol @code{Objects} are aggregated to @code{Node Objects}.
 Since there is no global protocol id in the system, we use the corresponding
-node id in file naming.  Threfore there is a possibility for file name 
+node id in file naming.  Therefore there is a possibility for file name 
 collisions in automatically chosen trace file names.  For this reason, the
 file name convention is changed for protocol traces.
 
@@ -1179,7 +1179,7 @@ in the @code{ns-3} system are of the form ``<prefix>-<node id>-<device id>.tr''
 As previously mentioned, every node in the system will have a system-assigned
 node id.  Since there is a one-to-one correspondence between protocols and nodes
 we use to node-id to identify the protocol identity.  Every interface on a 
-given rotocol will have an interface index (also called simply an interface) 
+given protocol will have an interface index (also called simply an interface) 
 relative to its protocol.  By default, then, an ascii trace file created as a result
 of enabling tracing on the first device of node 21, using the prefix ``prefix'',
 would be ``prefix-n21-i1.tr''.  Use the prefix to disambiguate multiple protocols
diff --git a/doc/manual/wimax.texi b/doc/manual/wimax.texi
index 1ec8c7d63..abcbf31d4 100644
--- a/doc/manual/wimax.texi
+++ b/doc/manual/wimax.texi
@@ -65,7 +65,7 @@ as well as ns-3 mobility models
 @item Initial Ranging
 @item Service Flow Initialization
 @item Management Connection
-@item Transport Intialization
+@item Transport Initialization
 @item UGS, rtPS, nrtPS, and BE connections
 @end itemize
 
diff --git a/doc/testing/background.texi b/doc/testing/background.texi
index 6a23a23b0..c8d80a1a9 100644
--- a/doc/testing/background.texi
+++ b/doc/testing/background.texi
@@ -33,7 +33,7 @@ misused.
 
 There are also a number of different philosophical approaches to software 
 testing.  For example, some organizations advocate writing test programs
-before actually imlementing the desired software, yielding ``test-driven 
+before actually implementing the desired software, yielding ``test-driven 
 development.''  Some organizations advocate testing from a customer perspective
 as soon as possible, following a parallel with the agile development process:
 ``test early and test often.''  This is sometimes called ``agile testing.''  It
@@ -92,7 +92,7 @@ not-so-slow PHY-level model of the 802.11a specification.''
 
 Once this is done, one can develop an abstract model of the target system.  This
 is typically an exercise in managing the tradeoffs between complexity, resource
-requiremens and accuracy.  The process of developing an abstract model has been
+requirements and accuracy.  The process of developing an abstract model has been
 called @emph{model qualification} in the literature.  In the case of a TCP 
 protocol, this process results in a design for a collection of objects, 
 interactions and behaviors that will fully implement RFC 793 in @command{ns-3}.
@@ -140,7 +140,7 @@ generating or simulating resource exhaustion of various kinds.  This genre of
 testing is called ``stress testing.''
 
 The system and its components may be exposed to so-called ``clean tests'' that
-demostrate a positive result -- that is that the system operates correctly in 
+demonstrate a positive result -- that is that the system operates correctly in 
 response to a large variation of expected configurations.  
 
 The system and its components may also be exposed to ``dirty tests'' which 
@@ -203,7 +203,7 @@ existing functionality.  There are many kinds of regressions that may occur
 in practice.
 
 A @emph{local regression} is one in which a change affects the changed component
-directy.  For example, if a component is modified to allocate and free memory
+directly.  For example, if a component is modified to allocate and free memory
 but stale pointers are used, the component itself fails.
 
 A @emph{remote regression} is one in which a change to one component breaks
diff --git a/doc/testing/testing-framework.texi b/doc/testing/testing-framework.texi
index 04bd1bb49..2f16ff990 100644
--- a/doc/testing/testing-framework.texi
+++ b/doc/testing/testing-framework.texi
@@ -68,7 +68,7 @@ undergo build and test cycles every day to verify that all is well.
 
 @node Testpy
 @section Test.py
-The buildbots use a Python program, @command{test.py}, that is reponsible for 
+The buildbots use a Python program, @command{test.py}, that is responsible for 
 running all of the tests and collecting the resulting reports into a human-
 readable form.  This program is also available for use by users and developers
 as well.
@@ -107,7 +107,7 @@ This mode is indented to be used by users who are interested in determining if
 their distribution is working correctly, and by developers who are interested
 in determining if changes they have made have caused any regressions.
 
-There are a number of options available to control the behavir of @code{test.py}.
+There are a number of options available to control the behavior of @code{test.py}.
 if you run @code{test.py --help} you should see a command summary like:
 
 @verbatim
diff --git a/doc/tutorial/building-topologies.texi b/doc/tutorial/building-topologies.texi
index dcdcbdf5e..d129fde7e 100644
--- a/doc/tutorial/building-topologies.texi
+++ b/doc/tutorial/building-topologies.texi
@@ -710,7 +710,7 @@ happen in a real Ethernet.  This is not the case.
 A model is, by definition, an abstraction of reality.  It is ultimately the 
 responsibility of the simulation script author to determine the so-called
 ``range of accuracy'' and ``domain of applicability'' of the simulation as
-a whole, and therefore its consitiuent parts.
+a whole, and therefore its constituent parts.
 
 In some cases, like @code{Csma}, it can be fairly easy to determine what is 
 @emph{not} modeled.  By reading the model description (@code{csma.h}) you 
@@ -754,7 +754,7 @@ not reflect the reality you might be expecting.
 
 Just to complicate the picture, there exist jumbo frames (1500 < MTU <= 9000 bytes)
 and super-jumbo (MTU > 9000 bytes) frames that are not officially sanctioned
-by IEEE but are avialable in some high-speed (Gigabit) networks and NICs.  One
+by IEEE but are available in some high-speed (Gigabit) networks and NICs.  One
 could leave the encapsulation mode set to @code{Dix}, and set the @code{Mtu}
 @code{Attribute} on a @code{CsmaNetDevice} to 64000 bytes -- even though an 
 associated @code{CsmaChannel DataRate} was set at 10 megabits per second.  
diff --git a/doc/tutorial/getting-started.texi b/doc/tutorial/getting-started.texi
index 6aa102400..e4266e2a4 100644
--- a/doc/tutorial/getting-started.texi
+++ b/doc/tutorial/getting-started.texi
@@ -415,7 +415,7 @@ default or require support from the underlying system to work properly.
 For instance, to enable XmlTo, the library libxml-2.0 must be found on the
 system.  If this library were not found, the corresponding @command{ns-3} feature 
 would not be enabled and a message would be displayed.  Note further that there is 
-a feature to use the progarm @code{sudo} to set the suid bit of certain programs.
+a feature to use the program @code{sudo} to set the suid bit of certain programs.
 This is not enabled by default and so this feature is reported as ``not enabled.''
 
 Now go ahead and switch back to the debug build.
diff --git a/doc/tutorial/in-process/introduction.texi b/doc/tutorial/in-process/introduction.texi
index 58ff959bd..0aa87389e 100644
--- a/doc/tutorial/in-process/introduction.texi
+++ b/doc/tutorial/in-process/introduction.texi
@@ -20,7 +20,7 @@ other important resources that are available to those interested in using or
 writing scripts, models and even those interested in making contributions to
 the core ns-3 system.  We provide an overview of some of the 
 important abstractions, design patterns and idioms used when writing 
-ns-3 scripts, and then dig right in by begining to write simulation 
+ns-3 scripts, and then dig right in by beginning to write simulation 
 scripts, run them and interpret results.
 
 After completing this tutorial, one should be able to:
@@ -749,8 +749,8 @@ an easy to use model.
 Topology helper functions use the abstractions (described above) of Network
 Interface Cards and Cables.  When you think of adding a new kind of network,
 you may think of going out to the local computer retailer and buying a kit.
-This kit might include a nework cable and some number of peripheral cards and
-thier associated software drivers.  You can think of topology helpers in 
+This kit might include a network cable and some number of peripheral cards and
+their associated software drivers.  You can think of topology helpers in 
 roughly the same way.  Instead of buying a kit for a given type of network,
 you will use a topology helper class for a given type of network, to accomplish
 the equivalent of installing the network ``kit.''
@@ -758,7 +758,7 @@ the equivalent of installing the network ``kit.''
 @section Important Idioms
 Now that we have identified that there are C++ classes in the system called
 @code{Node} and @code{InternetNode}, we need to understand how to bring
-objects of these classes into existance, and manage their lifetimes.  Let's
+objects of these classes into existence, and manage their lifetimes.  Let's
 examine this in some detail here.
 
 @cindex InternetNode
@@ -1164,7 +1164,7 @@ To summarize: The magic happens in the assignment operator.  Class
 Therefore, there exists a standard conversion from an @code{InternetNode *} 
 to a @code{Node *} and by extension from an @code{InternetNode &} to a
 @code{Node &}.  This conversion is applied automatically (and invisibly) 
-during paramater passing in the assignment operator we are examining.
+during parameter passing in the assignment operator we are examining.
 
 @cindex base class
 This is a rather involved way of saying there's an invisible pointer cast
@@ -1202,7 +1202,7 @@ like:
 @cindex InternetNode
 @cindex smart pointer
 Now we know that this is really a simple statement.  We create an
-@code{InternetNode} object on the heap (indirecly using operator @code{new}
+@code{InternetNode} object on the heap (indirectly using operator @code{new}
 and passing no parameters to its constructor) and assign responsibility for
 managing the new object's lifetime to a smart pointer.  This smart pointer is 
 a pointer to a @code{Node} object, so there was a hidden cast from 
@@ -1366,7 +1366,7 @@ was used in the example):
 @end itemize
 
 C++ will attempt to promote parameters appropriately, but you will typically
-see constructions that respect the type corrrectness of the constructor, as
+see constructions that respect the type correctness of the constructor, as
 in @code{Seconds (1.)} and @code{MilliSeconds (2)}.  Notice that the code
 @code{Seconds (1)} will work just as well as @code{Seconds (1.)} since the 
 integer 1 will be automatically promoted to a double 1. in the former code.
@@ -1547,7 +1547,7 @@ application as named parameters for clarity.  We are telling the application
 to generate 1024 byte packets (@code{packetSize = 1024}); and to send these
 packets to port 7 (@code{port = 7;}).  The application is told to send at most
 one packet (@code{maxPacketCount = 1;}); and to delay for one second between
-packet sends (@code{interpacketInterval = Seconds(1.)}) which is not used since
+packet sends (@code{interPacketInterval = Seconds(1.)}) which is not used since
 only one packet is sent.  We will defer addressing the type @code{Time} until
 we discuss the simulator engine.  For now just understand the semantics are
 to wait for one second.
@@ -1780,17 +1780,17 @@ In ns-3 an event is basically a pre-packaged function call called a
 a more descriptive term --- an object (in the object-oriented programming 
 sense) that can be called as if it was a function.  Typically one uses a
 functor to implement @emph{deferred execution} of a function or method.  The
-most commonly encoutered form of deferred execution is in a @emph{callback}
+most commonly encountered form of deferred execution is in a @emph{callback}
 from an I/O system.  In this case, the goal would be to start an I/O
 operation and return immediately, without having to wait for the operation 
-to complete.  One asks the I/O subsytem to notify you when an operation is
+to complete.  One asks the I/O subsystem to notify you when an operation is
 complete by calling some function you provide.  This provided function is
 known as a callback function.  [Imagine calling someone on the telephone and
 asking them to do something for you.  You also ask them to @emph{call you back}
 when they are done.]  Events in the ns-3 system work conceptually
 the same way, except that instead of an I/O completion driving the process,
 the arrival of some simulated time drives the process.  The ns-3 
-deferred exectution mechanism is via a class called @code{Callback}.
+deferred execution mechanism is via a class called @code{Callback}.
 
 @cindex Time
 @cindex Callback
diff --git a/doc/tutorial/in-process/other.texi b/doc/tutorial/in-process/other.texi
index 7b24e7809..5660ae496 100644
--- a/doc/tutorial/in-process/other.texi
+++ b/doc/tutorial/in-process/other.texi
@@ -584,7 +584,7 @@ have been changed.
 
 Next, we create a point to point link to connect the two lans.  We connect
 the point-to-point channel between nodes three (on the left lan) and four
-(on the right lan).  You should recoginze this as substantially similar to
+(on the right lan).  You should recognize this as substantially similar to
 the link setup from the @code{point-to-point} example.
 
 @verbatim
@@ -735,7 +735,7 @@ give you a starting point for required classes and member variables.
 Immediately we can notice that at the highest level we are talking about the
 noun @emph{network}.  This probably won't surprise you.  We also have an 
 adjective that modifies the noun --- @emph{bus}.  This should lead us to our 
-first class defintion.  Usually class names are constructed in the same way
+first class definition.  Usually class names are constructed in the same way
 as an English language sentence would be spoken.  For example, one would speak
 of a @emph{bus network} in conversation, so we would normally create a
 @code{class BusNetwork} to represent it.  
@@ -901,7 +901,7 @@ after this initialization.  They are:
     Ipv4AddressGenerator::SeedAddress (mask, baseAddress);
 @end verbatim
 
-We provide an IP address generator class to allow us to programatically 
+We provide an IP address generator class to allow us to programmatically
 allocate IP addresses.  The first call to @code{SeedNetwork} gives the
 address generator a starting network number to use when generating addresses.
 The second call to @code{SeedAddress} gives the address generator a starting
@@ -1011,7 +1011,7 @@ relatively abstract bus class, we can create bus networks with 4, 40 or 4000
 nodes with no additional effort.
 
 A use of the bus network class is shown in the file 
-@code{bus-netowrk.cc} located in the @code{tutorial} directory.  The
+@code{bus-network.cc} located in the @code{tutorial} directory.  The
 interesting code is,
 
 @verbatim
@@ -1058,7 +1058,7 @@ In the next part of the tutorial we are going to drop down a level and begin
 examining the lower levels of the system in more detail.  We are going to
 explain how to change the behavior of the system and eventually how to write
 new models and applications.  This is a good time to make sure that you
-thorougly understand what we've gone over so far.
+thoroughly understand what we've gone over so far.
 
 @c ========================================================================
 @c Object Model
@@ -1365,7 +1365,7 @@ its aggregation via the method @code{GetObject}.
 Technically, the class named @code{Object} is simply a base class that you
 will inherit from if you want your @code{Objects} to support aggregation and
 discovery.  Many systems have a base class that implements common 
-functionality and these base classes are typically called somthing like 
+functionality and these base classes are typically called something like 
 Object.  The @command{ns-3} version of this base class relates primarily to
 @code{Object} aggregation and discovery, although it does also provide methods
 to help with intrusive reference counting and tracing as well.
@@ -1383,7 +1383,7 @@ rather than with the form of the class declaration.
 For those of you unfamiliar with Microsoft COM, CORBA or ORBit, this might 
 sound obvious.  For those of with such a background, the point we are making 
 is that there is no such thing in @command{ns-3} as a separate Interface
-declaration, no such thing as an Interface Definiition Language, no such thing
+declaration, no such thing as an Interface Definition Language, no such thing
 as a UUID or GUID, etc.  In @command{ns-3} we just work with C++ objects that
 may be given some very useful abilities by inheriting from the @command{ns-3}
 base class @code{Object}.  @command{Ns-3} @code{Objects} are not required to
@@ -1422,7 +1422,7 @@ mentioned that the @code{Node} class acts as a container.  In fact, the
 @code{Object}.  So, when the @code{Node} object is created it is really an 
 aggregation of one @code{Object} and you can call @code{AggregateObject} or
 @code{GetObject} on the resulting @code{Node} object.  Along with being an
-aggregation, the @code{Node} class also describes a public interface.  THis
+aggregation, the @code{Node} class also describes a public interface.  This
 public interface (API) is declared just as any C++ object is declared, via its
 class methods as specified in the inheritance tree.  For those steeped in 
 COM or CORBA, this is where the concept of Interface works in @command{ns-3}.
@@ -1531,7 +1531,7 @@ The right hand side illustrates how @code{GetObject} is acutally used.
 The method @code{GetObject} is templated.  The assocated template parameter 
 (between the brackets) specifies the @emph{class} that is being requested.
 This is important.  Since it is the class type that specifies the search
-criteron, there can be only one instance of a particular class present in an
+criterion, there can be only one instance of a particular class present in an
 aggregation.  Looking back a little, although the parameter to
 @code{AggregateObject} appears to be a vanilla C++ object (@code{b} or @code{c}
 above), it actually represents (is an instance of) a class that has an
@@ -1648,7 +1648,7 @@ If you can get to @code{Object B} from @code{Object A}, and you can get to
 @cindex TypeId
 @cindex GetTypeId
 The final piece of this puzzle is the @code{TypeId}.  Recall that the
-declaration our eample object above included the following code
+declaration our example object above included the following code
 
 @verbatim
   static ns3::TypeId GetTypeId (void)
diff --git a/doc/tutorial/in-process/output.texi b/doc/tutorial/in-process/output.texi
index 185608b42..7e3813c02 100644
--- a/doc/tutorial/in-process/output.texi
+++ b/doc/tutorial/in-process/output.texi
@@ -72,7 +72,7 @@ For Internet nodes, the ASCII trace wrapper is a wrapper around
 the @command{ns-3} low-level 
 tracing system that lets you get access to underlying trace events easily.  
 The output of a trace of a simulation run is an ASCII file --- thus the name.  
-In the spririt of keeping things simple, you won't be able to control or 
+In the spirit of keeping things simple, you won't be able to control or 
 configure the output at this stage.
 
 For those familiar with @command{ns-2} output, this type of trace is
@@ -191,7 +191,7 @@ is created it is given an identifying number that monotonically increases from
 zero.  Therefore, @code{nodeid=0} means that the node in which the given trace
 event originated is the first node we created.  In the case of our script, 
 this first node is is the node pointed to by the smart pointer @code{n0}.  Not
-too surpsisingly, this is also the node to which we attached the
+too surprisingly, this is also the node to which we attached the
 @code{UdpEchoClient}.  The device number is local to each node, and so the
 device given by @code{device=0} is the first net device that we added to the
 node in question.  In our simulation, this corresponds to the 
@@ -339,7 +339,7 @@ one has received the UDP echo packet and the @code{UdpEchoServer Application}
 on that node has turned the packet around.  Just as node zero needed to ARP
 for the MAC address of node one, now node one must ARP for the MAC address of
 node zero.  We see the ARP request enqueued on the transmit queue of node one;
-then we see the ARP request dequeued from the tranmit queue of node one (and
+then we see the ARP request dequeued from the transmit queue of node one (and
 implicitly transmitted to node zero).  Then we see an ARP response enqueued
 on the transmit queue of node zero; and finally the ARP response dequeued (and
 implicitly transmitted back to node one).
@@ -396,7 +396,7 @@ tcpdump and Wireshark can be used..
 The code used to enable pcap tracing is similar to that for ASCII tracing.  
 We have provided another file, @code{tutorial-csma-echo-pcap-trace.cc} that 
 uses the pcap trace wrapper.  We have added the code to include the pcap 
-trace wrapper defintions:
+trace wrapper definitions:
 
 @verbatim
   #include "ns3/pcap-trace.h"
@@ -447,7 +447,7 @@ those nodes.
 
 @subsubsection Reading output with Wireshark
 @cindex Wireshark
-If you are unfamilar with Wireshark, there is a web site available from which
+If you are unfamiliar with Wireshark, there is a web site available from which
 you can download programs and documentation:  @uref{http://www.wireshark.org/}.
 
 If you have Wireshark available, you can open each of the trace files and
diff --git a/doc/tutorial/tracing.texi b/doc/tutorial/tracing.texi
index f655faaca..088e33b75 100644
--- a/doc/tutorial/tracing.texi
+++ b/doc/tutorial/tracing.texi
@@ -34,7 +34,7 @@ mechanisms and parsing their content to extract interesting information; or
 somehow developing an output mechanism that conveys exactly (and perhaps only) 
 the information wanted.
 
-Using pre-defined bulk output mechansims has the advantage of not requiring any
+Using pre-defined bulk output mechanisms has the advantage of not requiring any
 changes to @code{ns-3}, but it does require programming.  Often, pcap or NS_LOG
 output messages are gathered during simulation runs and separately run through 
 scripts that use grep, sed or awk to parse the messages and reduce and transform
@@ -761,7 +761,7 @@ The difference is due to the fact that two @code{GetObject} calls are implied
 in the string found in the documentation.  The first, for @code{$ns3::MobilityModel}
 will query the aggregation for the base class.  The second implied 
 @code{GetObject} call, for @code{$ns3::RandomWalk2dMobilityModel}, is used to ``cast''
-the base class to the concrete imlementation class.  The documentation shows 
+the base class to the concrete implementation class.  The documentation shows 
 both of these operations for you.  It turns out that the actual Attribute you are
 going to be looking for is found in the base class as we have seen.
 
@@ -1476,7 +1476,7 @@ as a result of the @code{apps.Start} call and
 
 as a result of the @code{apps.Stop} call.
 
-The ulitmate result of these calls is that we want to have the simulator 
+The ultimate result of these calls is that we want to have the simulator 
 automatically make calls into our @code{Applications} to tell them when to
 start and stop.  In the case of @code{MyApp}, it inherits from class
 @code{Application} and overrides @code{StartApplication}, and 
@@ -1532,7 +1532,7 @@ Take a look at @code{src/core/object.cc} next and search for @code{Object::Start
 This code is not as straightforward as you might have expected since 
 @command{ns-3} @code{Objects} support aggregation.  The code in 
 @code{Object::Start} then loops through all of the objects that have been
-aggretated together and calls their @code{DoStart} method.  This is another
+aggregated together and calls their @code{DoStart} method.  This is another
 idiom that is very common in @command{ns-3}.  There is a public API method,
 that stays constant across implementations, that calls a private implementation
 method that is inherited and implemented by subclasses.  The names are typically
@@ -1730,7 +1730,7 @@ has sent enough.
   }
 @end verbatim
 
-Here, you see that @code{ScheduleTx} does exactly that.  If the @code{Applciation}
+Here, you see that @code{ScheduleTx} does exactly that.  If the @code{Application}
 is running (if @code{StopApplication} has not been called) it will schedule a 
 new event, which calls @code{SendPacket} again.  The alert reader will spot
 something that also trips up new users.  The data rate of an @code{Application} is
@@ -2297,7 +2297,7 @@ of specifying which traces should be enabled through a node, device pair.  For
 example, you may want to specify that pcap tracing should be enabled on a 
 particular device on a specific node.  This follows from the @code{ns-3} device
 conceptual model, and also the conceptual models of the various device helpers.
-Following naturallyu from this, the files created follow a 
+Following naturally from this, the files created follow a 
 <prefix>-<node>-<device> naming convention.  
 
 Protocol helpers look at the problem of specifying which traces should be
@@ -2480,7 +2480,7 @@ Finally, two of the methods shown above,
 
 @verbatim
   void EnablePcap (std::string prefix, Ptr<NetDevice> nd, bool promiscuous = false, bool explicitFilename = false);
-  void EnablePcap (std::string prefix, std::string ndName, bool promiscuous = false, bool explicitFilenaqme = false);
+  void EnablePcap (std::string prefix, std::string ndName, bool promiscuous = false, bool explicitFilename = false);
 @end verbatim
 
 have a default parameter called @code{explicitFilename}.  When set to true,
@@ -2876,7 +2876,7 @@ taken for devices in the @code{ns-3} system are of the form
 there is a one-to-one correspondence between protocols and @code{Nodes}.
 This is because protocol @code{Objects} are aggregated to @code{Node Objects}.
 Since there is no global protocol id in the system, we use the corresponding
-node id in file naming.  Threfore there is a possibility for file name 
+node id in file naming.  Therefore there is a possibility for file name 
 collisions in automatically chosen trace file names.  For this reason, the
 file name convention is changed for protocol traces.
 
@@ -3133,7 +3133,7 @@ in the @code{ns-3} system are of the form ``<prefix>-<node id>-<device id>.tr''
 As previously mentioned, every node in the system will have a system-assigned
 node id.  Since there is a one-to-one correspondence between protocols and nodes
 we use to node-id to identify the protocol identity.  Every interface on a 
-given rotocol will have an interface index (also called simply an interface) 
+given protocol will have an interface index (also called simply an interface) 
 relative to its protocol.  By default, then, an ascii trace file created as a result
 of enabling tracing on the first device of node 21, using the prefix ``prefix'',
 would be ``prefix-n21-i1.tr''.  Use the prefix to disambiguate multiple protocols
@@ -3164,7 +3164,7 @@ collection of pre-defined outputs to a fine granularity.  There are mid-level
 helper functions to allow more sophisticated users to customize how information
 is extracted and saved; and there are low-level core functions to allow expert
 users to alter the system to present new and previously unexported information
-in a way that will be immediatly accessible to users at higher levels.
+in a way that will be immediately accessible to users at higher levels.
 
 This is a very comprehensive system, and we realize that it is a lot to 
 digest, especially for new users or those not intimately familiar with C++
diff --git a/doc/tutorial/tweaking.texi b/doc/tutorial/tweaking.texi
index 87baffb35..84ad60361 100644
--- a/doc/tutorial/tweaking.texi
+++ b/doc/tutorial/tweaking.texi
@@ -628,7 +628,7 @@ to some other value than one.
 How would you go about that?  Give it a try.  Remember you have to comment 
 out the place we override the default @code{Attribute} and explicitly set 
 @code{MaxPackets} in the script.  Then you have to rebuild the script.  You 
-will also have to find the syntax for actually setting the new default atribute
+will also have to find the syntax for actually setting the new default attribute
 value using the command line help facility.  Once you have this figured out 
 you should be able to control the number of packets echoed from the command 
 line.  Since we're nice folks, we'll tell you that your command line should 
@@ -1037,7 +1037,7 @@ the client in the first dump at 2.514648 seconds.
 
 @subsubsection Reading output with Wireshark
 @cindex Wireshark
-If you are unfamilar with Wireshark, there is a web site available from which
+If you are unfamiliar with Wireshark, there is a web site available from which
 you can download programs and documentation:  @uref{http://www.wireshark.org/}.
 
 Wireshark is a graphical user interface which can be used for displaying these
diff --git a/src/node/net-device.h b/src/node/net-device.h
index 17e290d0b..b1e0fcaed 100644
--- a/src/node/net-device.h
+++ b/src/node/net-device.h
@@ -167,7 +167,7 @@ public:
    * encapsulated in an abstract Address to avoid dependencies on the exact
    * MAC address format.
    *
-   * A default imlementation of GetMulticast is provided, but this
+   * A default implementation of GetMulticast is provided, but this
    * method simply NS_ASSERTS.  In the case of net devices that do not support
    * multicast, clients are expected to test NetDevice::IsMulticast and avoid
    * attempting to map multicast packets.  Subclasses of NetDevice that do