From ac4aaa1630332d347667fabed8a6d34a605d0115 Mon Sep 17 00:00:00 2001
From: Dirk Loss <mail@dirk-loss.de>
Date: Sun, 15 Mar 2009 23:24:32 +0100
Subject: [PATCH] Fixed more typos and minor layout issues
---
doc/scapy/advanced_usage.rst | 16 +++++++++-------
doc/scapy/build_dissect.rst | 33 +++++++++++++++++----------------
2 files changed, 26 insertions(+), 23 deletions(-)
diff --git a/doc/scapy/advanced_usage.rst b/doc/scapy/advanced_usage.rst
index 5b4d0b9b..0ae21999 100644
--- a/doc/scapy/advanced_usage.rst
+++ b/doc/scapy/advanced_usage.rst
@@ -115,7 +115,7 @@ Encoding and decoding are done using class methods provided by the codec. For ex
>>> BERcodec_Object.dec('\x03\x03egg')
(<ASN1_BIT_STRING['egg']>, '')
-ASN.1 objects are encoded using their ``.enc()`` method. This method must be called with the codec we want to use. All codecs are referenced in the ASN1_Codecs object. str() can also be used. In this case, the default codec (``conf.ASN1_default_codec``) will be used.
+ASN.1 objects are encoded using their ``.enc()`` method. This method must be called with the codec we want to use. All codecs are referenced in the ASN1_Codecs object. ``str()`` can also be used. In this case, the default codec (``conf.ASN1_default_codec``) will be used.
::
@@ -493,7 +493,7 @@ It is even possible to graph it::
Automata
========
-Scapy enables to create esaily network automata. Scapy does not stick to a specific model like Moore or Mealy automata. It provides a flexible way for you to choose you way to go.
+Scapy enables to create easily network automata. Scapy does not stick to a specific model like Moore or Mealy automata. It provides a flexible way for you to choose you way to go.
An automaton in Scapy is deterministic. It has different states. A start state and some end and error states. There are transitions from one state to another. Transitions can be transitions on a specific condition, transitions on the reception of a specific packet or transitions on a timeout. When a transition is taken, one or more actions can be run. An action can be bound to many transitions. Parameters can be passed from states to transitions and from transitions to states and actions.
@@ -502,7 +502,7 @@ From a programmer's point of view, states, transitions and actions are methods f
First example
-------------
-Let's begin with a simple example. I take the convention to write states with capitals, but anything valid with python syntax would work as well.
+Let's begin with a simple example. I take the convention to write states with capitals, but anything valid with Python syntax would work as well.
::
@@ -526,9 +526,11 @@ Let's begin with a simple example. I take the convention to write states with ca
In this example, we can see 3 decorators:
- * ATMT.state that is used to indicate that a method is a state, and that can have initial, final and error optional arguments set to non-zero for special states.
- * ATMT.condition that indicate a method to be run when the automaton state reaches the indicated state. The argument is the name of the method representing that state
- * ATMT.action binds a method to a transition and is run when the transition is taken.
+* ``ATMT.state`` that is used to indicate that a method is a state, and that can
+ have initial, final and error optional arguments set to non-zero for special states.
+* ``ATMT.condition`` that indicate a method to be run when the automaton state
+ reaches the indicated state. The argument is the name of the method representing that state
+* ``ATMT.action` binds a method to a transition and is run when the transition is taken.
Running this example gives the following result::
@@ -704,7 +706,7 @@ States are methods decorated by the result of the ``ATMT.state`` function. It ca
Decorators for transitions
~~~~~~~~~~~~~~~~~~~~~~~~~~
-Transitions are methods decorated by the result of one of ``ATMT.condition``, ``ATMT.receive_condition``, ``ATMT.timeout``. They all take as argument the state method they are related to. ATMT.timeout also have a mandatory ``timeout`` parameter to provide the timeout value in seconds. ``ATMT.condition`` and ``ATMT.receive_condition`` have an optional ``prio`` parameter so that the order in which conditions are evaluated can be forced. Default priority is 0. Transitions with the same priority level are called in an undetermined order.
+Transitions are methods decorated by the result of one of ``ATMT.condition``, ``ATMT.receive_condition``, ``ATMT.timeout``. They all take as argument the state method they are related to. ``ATMT.timeout`` also have a mandatory ``timeout`` parameter to provide the timeout value in seconds. ``ATMT.condition`` and ``ATMT.receive_condition`` have an optional ``prio`` parameter so that the order in which conditions are evaluated can be forced. Default priority is 0. Transitions with the same priority level are called in an undetermined order.
When the automaton switches to a given state, the state's method is executed. Then transitions methods are called at specific moments until one triggers a new state (something like ``raise self.MY_NEW_STATE()``). First, right after the state's method returns, the ``ATMT.condition`` decorated methods are run by growing prio. Then each time a packet is received and accepted by the master filter all ``ATMT.receive_condition`` decorated hods are called by growing prio. When a timeout is reached since the time we entered into the current space, the corresponding ``ATMT.timeout`` decorated method is called.
diff --git a/doc/scapy/build_dissect.rst b/doc/scapy/build_dissect.rst
index 79287417..f621e7ca 100644
--- a/doc/scapy/build_dissect.rst
+++ b/doc/scapy/build_dissect.rst
@@ -72,7 +72,7 @@ organized.
>>> p.summary()
'IP / TCP 127.0.0.1:ftp-data > 127.0.0.1:www S / Raw'
-We are interested in 2 "inside" fields of the class Packet:
+We are interested in 2 "inside" fields of the class ``Packet``:
* ``p.underlayer``
* ``p.payload``
@@ -312,7 +312,7 @@ dissected. ``self`` points to the current layer.
dissected as "``Raw``" data (which is some kind of default layer type)
-For a given layer, everything is quite straightforward.
+For a given layer, everything is quite straightforward:
- ``pre_dissect()`` is called to prepare the layer.
- ``do_dissect()`` perform the real dissection of the layer.
@@ -407,13 +407,13 @@ Sometimes, guessing the payload class is not as straightforward as
defining a single port. For instance, it can depends on a value of a
given byte in the current layer. The 2 needed methods are:
- - ``guess_payload_class()`` which must return the guessed class for the
- payload (next layer). By default, it uses links between classes
- that have been put in place by ``bind_layers()``.
+- ``guess_payload_class()`` which must return the guessed class for the
+ payload (next layer). By default, it uses links between classes
+ that have been put in place by ``bind_layers()``.
- - ``default_payload_class()`` which returns the default value. This
- method defined in the class ``Packet`` returns ``Raw``, but it can be
- overloaded.
+- ``default_payload_class()`` which returns the default value. This
+ method defined in the class ``Packet`` returns ``Raw``, but it can be
+ overloaded.
For instance, decoding 802.11 changes depending on whether it is
ciphered or not::
@@ -427,12 +427,12 @@ ciphered or not::
Several comments are needed here:
- - this cannot be done using ``bind_layers()`` because the tests are
- supposed to be "``field==value``", but it is more complicated here as we
- test a single bit in the value of a field.
+- this cannot be done using ``bind_layers()`` because the tests are
+ supposed to be "``field==value``", but it is more complicated here as we
+ test a single bit in the value of a field.
- - if the test fails, no assumption is made, and we plug back to the
- default guessing mechanisms calling ``Packet.guess_payload_class()``
+- if the test fails, no assumption is made, and we plug back to the
+ default guessing mechanisms calling ``Packet.guess_payload_class()``
Most of the time, defining a method ``guess_payload_class()`` is not a
necessity as the same result can be obtained from ``bind_layers()``.
@@ -468,8 +468,8 @@ default method ``Packet.guess_payload_class()``. This method runs through
each element of the list payload_guess, each element being a
tuple:
- - the 1st value is a field to test (``'dport': 2000``)
- - the 2nd value is the guessed class if it matches (``Skinny``)
+- the 1st value is a field to test (``'dport': 2000``)
+- the 2nd value is the guessed class if it matches (``Skinny``)
So, the default ``guess_payload_class()`` tries all element in the list,
until one matches. If no element are found, it then calls
@@ -511,7 +511,7 @@ appended altogether.
0010 7F 00 00 01 00 14 00 50 00 00 00 00 00 00 00 00 .......P........
0020 50 02 20 00 91 7C 00 00 P. ..|..
-Calling str() builds the packet:
+Calling ``str()` builds the packet:
- non instanced fields are set to their default value
- lengths are updated automatically
- checksums are computed
@@ -906,6 +906,7 @@ e.g.::
Strings
-------
+::
StrField(name, default, fmt="H", remain=0, shift=0)
StrLenField(name, default, fld=None, length_from=None, shift=0):
--
GitLab