diff -Nru niceshaper-1.2.3/debian/changelog niceshaper-1.2.4/debian/changelog --- niceshaper-1.2.3/debian/changelog 2016-06-18 19:13:53.000000000 +0000 +++ niceshaper-1.2.4/debian/changelog 2016-12-27 22:52:52.000000000 +0000 @@ -1,3 +1,18 @@ +niceshaper (1.2.4-1) unstable; urgency=medium + + * New upstream release. + - Auto Hosts feature added. + - Status, show, and stop commands work even if errors in global section + configuration are found. + - Fix a bug where the commands status and show with --remote parameter + don't work if NiceShaper is not running locally. + - Allow additional dashes within the iface directive. + - Language fixes and updates introduced into the English translation + of documentation. + * Fix watch file to check for stable releases only. + + -- Mariusz Jedwabny Tue, 27 Dec 2016 23:52:52 +0100 + niceshaper (1.2.3-1) unstable; urgency=low * New upstream release. diff -Nru niceshaper-1.2.3/debian/control niceshaper-1.2.4/debian/control --- niceshaper-1.2.3/debian/control 2016-04-17 19:14:12.000000000 +0000 +++ niceshaper-1.2.4/debian/control 2016-12-27 22:52:52.000000000 +0000 @@ -12,14 +12,22 @@ Depends: ${shlibs:Depends}, ${misc:Depends}, iproute2 Recommends: iptables Description: Dynamic Traffic Shaper - NiceShaper is a program working in a Linux router environment. - It uses a proven HTB QOS algorithm. It provides dynamic traffic shaping - which is more effective than traditional, static shaping. - By constantly monitoring packets flowing through the router in response to - changing load dynamically adjusts the bandwidth of acting classes to a level - enabling the fullest possible usage of a internet access. - At the same time does not allow for creation of congestion, - ensuring complete convenience of interactive services. + NiceShaper is the program developed for Linux router environment. + It works in user space on top of standard Linux QOS implementation + and iptables. By default, a proven HTB algorithm is used for the root, inner, + and leaf classes, SFQ packets scheduling algorithm is the default queuing + discipline (qdisc) contained within each of leaf classes, U32 and FW are + used as the packets classifiers. NiceShaper provides dynamic traffic shaping + approach which is more effective than traditional shaping with static rates. + While constantly monitoring the traffic flowing through the router, + in response to the changing load, dynamically adjusts the rate and ceil + parameters values of enabled HTB classes to the values which enable + the fullest possible utilization of Internet connection throughput. . - NiceShaper protects each class which use reasonable amount of bandwidth and - takes care of overall download when upload is close to stop up. + NiceShaper protects each host which uses reasonable amount of shared + throughput while watching over the configured optimal utilization of + Internet connection. Therefore, at the asymmetric Internet connection, + takes care of download when upload is close to stop up (and vice versa). + NiceShaper doesn't allow for creation of congestions, + thus ensures the comfort of using interactive services as well. + diff -Nru niceshaper-1.2.3/debian/watch niceshaper-1.2.4/debian/watch --- niceshaper-1.2.3/debian/watch 2013-07-19 13:23:04.000000000 +0000 +++ niceshaper-1.2.4/debian/watch 2016-12-27 22:52:52.000000000 +0000 @@ -1,4 +1,4 @@ version=3 -http://niceshaper.jedwabny.net/files/niceshaper-(.*)\.tar\.bz2 +http://niceshaper.jedwabny.net/files/niceshaper-(\d\.\d\.\d+)\.tar\.bz2 diff -Nru niceshaper-1.2.3/docs/en/changelog.html niceshaper-1.2.4/docs/en/changelog.html --- niceshaper-1.2.3/docs/en/changelog.html 2016-06-04 20:09:43.000000000 +0000 +++ niceshaper-1.2.4/docs/en/changelog.html 2016-12-27 21:55:03.000000000 +0000 @@ -12,6 +12,31 @@

ChangeLog

+

[NiceShaper 1.2.4 2016-12-26]

+ +Most important changes and new features: + +
+ +
+ +Fixes: + +
+ +
+

[NiceShaper 1.2.3 2016-06-03]

diff -Nru niceshaper-1.2.3/docs/en/documentation.html niceshaper-1.2.4/docs/en/documentation.html --- niceshaper-1.2.3/docs/en/documentation.html 2016-06-04 20:09:43.000000000 +0000 +++ niceshaper-1.2.4/docs/en/documentation.html 2016-12-27 21:55:03.000000000 +0000 @@ -23,9 +23,9 @@
  • Hosts and classes in NiceShaper
  • Macros of the class.conf file
  • Packet marking
    • -
  • Usage of IMQ interfaces
    • +
  • Using IMQ interfaces
  • Triggers
    • -
  • Router's self generated traffic shaping
    • +
  • Shaping of Router self generated traffic
  • Advanced topics
    • @@ -33,6 +33,7 @@ @@ -40,144 +41,101 @@

    Introduction and requirements

    -NiceShaper works to give you optimal bandwidth utilization and simplify of configure traffic shaping in Linux Operating System which can be really complex. I always seek when creating solutions to makes them flexible, intuitive and clear. To makes them be tool for simplify what is to much complex and at once gives ability to configure everything what is worth to have control on. +Configuring traffic shaping in Linux could be quite complex task. The main goals of NiceShaper are to be intuitive and flexible. This approach is achieved by simplifying things which are not easy in HTB, it means giving the ability to use the selected subset of QOS features which are the most important to have available. However, also adding additional features.

    -It's possible to create an entry configuration without reading this documentation. It's thanks to example configuration files included in program package. Solid knowledge of networks is prerequisite. Keep in mind, when you get first look at included example configuration files next it is worth to look on this documentation unless you don't want to create optimal traffic shaping. NiceShaper really seeks but can't outguess all your needs so knowledge of IP network and Linux System is helpful. Still don't be fear when you do not understand everything here, keep in mind that this documentation is far beyond your needs for the first time. After all NiceShaper goal is simplify what in HTB is hard and at once to gives you additional features. +For sure, it's possible to create an entry configuration without reading this documentation document using example configuration files included in the program package. At least solid knowledge about IP networks is rather must to have. So, let's adjust internet access parameters, in /etc/niceshaper/config.conf file, and collect the hosts or classes list in /etc/niceshaper/class.conf file, then execute the niceshaper start command. It's done! Just so simple to start using NiceShaper. Use the niceshaper status command to observe how it works. But, keep in mind, after you get the first look onto the examples, then it's worth to look on documentation unless you are not interesting in another features. Still, don't be fear when you do not understand everything here as it's far beyond of your needs for the beginning.

    -In minimal configuration you need router with your favorite Linux System, with installed iptables and compiled in kernel HTB and SFQ packet scheduling algorithms and U32 kernel filter. +In minimal configuration you need the router with your favourite Linux distribution. Iptables tool installed. HTB, SFQ packet scheduling algorithms, U32 and FW kernel filters compiled into the kernel. Hereinafter, HTB class means HTB packet scheduling class while NiceShaper class works on top of HTB class. Queuing algorithms means SFQ and the other classless queueing disciplines. Kernel filters means U32 and FW packets classifiers while NiceShaper filter works, again, on top of such kernel filters and/or iptables rules. In most popular Linux distributions HTB, SFQ, U32, and FW are by default compiled into the kernel or available as modules. Unfortunately, IMQ support is unusual to be compiled into the iptables and kernel.

    -Hereinafter HTB class means HTB packet scheduling class and NiceShaper class is in NiceShaper level. Queuing algorithms means SFQ and others classless queueing disciplines. Kernel filters means U32 and FW and it is not the same as NiceShaper filters which are on NiceShaper level of configuration. +For purpose of this documentation we assume that we have a router equipped with two interfaces. WAN is connected to the eth0 interface and LAN to the eth1. Example public IP address of the router is 198.51.100.100 and LAN network is 192.168.0.0/24.

    -In most popular Linux Distributions HTB, SFQ, U32 and FW filter are compiled in kernel or as modules by default. Iptables program too but apart from IMQ. +NiceShaper uses egress shaping approach for traffic shaping. Therefore, it's fundamental that classes which control the forwarded traffic have to be placed on the interface which is outbound for such traffic. So, in assumed environment, shaping of download traffic has to be placed on eth1, but shaping of upload traffic has to be placed on eth0. Why? Because, for above assumptions, downloaded packets incomes into the router via eth0 interface and then are sent to the local network via eth1 interface. It makes the eth1 the outbound interface for download. Explanation for opposite direction is analogical.

    -For purpose of this documentation we assume that we have a router equipped with two interfaces. WAN uplink is connected to interface eth0 and local LAN to eth1. Public address of the router is 198.51.100.100 and LAN network is 192.168.0.0/24. +Proper choose of outbound interfaces is crucial for configuration of NiceShaper hosts, classes, and several directives. For example, if LAN network is hidden behind NAT then it's needed to shape upload traffic using packet marking method. In this case, it's needed to put the egress interface (eth0) into the mark-on-iface directive. Additionally, IMQ interfaces as a workaround method for NAT problem are supported as well. Both, packets marking and IMQ interfaces are documented in hereafter.

    -As we discount poor ingress qdisc, it's fundamental that egress shaping occurs on outgoing interface, so, shaping of download traffic has to be placed on eth1 interface. On the other hand, shaping of upload traffic has to be placed on eth0. This is because the downloaded packets incomes via eth0 interface and outgoes to the local network via eth1 interface (for above assumptions!). Respectively, the uploaded packets incomes from local network via eth1 and outgoes to the internet via eth0 interface. It's all valid for above assumptions and may be required to be adjusted in configuration prepared for the other environment! +Once again, these example interfaces are valid for previous assumptions but not necessarily for your router.

    -Proper choose of interface is crucial to define hosts, classes, and some of configuration directives. For example, if LAN network is hidden behind NAT and we need to shape upload by packet marking method then we need to put it on eth0 by mark-on-iface eth0 directive. +Words about interfaces notation. Neither Iptables nor Iproute understand concept of the network interface aliases. Thus colon and alias number should be omitted from the configuration. It's completely safe. However, despite the fact that aliases does not matter, VLANs have to be indicated. The ethX.vid notation for tagged VLAN sub-interfaces is supported. While complementing about the VLANs in Linux, it's good to know that if you run traffic shaping on tagged sub-interface it's strongly suggested to completely abandon on the untagged main interface. Otherwise, you may find that kernel queues the tagged data frames twice. Once on tagged sub-interface and second time on physical one.

    -I would like to add that upload shaping of NATed network is also possible with IMQ interfaces. Both, packets marking and IMQ interfaces are documented in hereafter. -

    -Remember as these examples above are valid for previous assumes not necessarily for your router. -

    -For the end of the introduction. Iptables and Iproute do not understand concept of interface aliases, so in NiceShaper configurations you should omit colon and alias number from interface. It's safe. On the other side, VLANs written as ethX.vid are fully supported. -

    -Complementing about the VLANs in Linux. If you create the tagged sub-interface and run traffic shaping on it, you should completely abandon the untagged interface. Otherwise, you may find that the kernel queues tagged data frames twice. Once on tagged sub-interface and second time on physical one. -

    -NiceShaper has good scalability on the routers used by no more than half thousand of hosts - although there are notices about the NiceShaper usage in bigger networks. In such bigger networks there is rather a hash table requirement. Hash tables are unsupported so far, because of being too inflexible for NiceShaper needs. -

    -Please be aware that NiceShaper has been written for polish Network Administrators since start of the project, so there is a forum on the web page but it is useless for you because of polish language. Also you should realise that this documentation can be strongly language incorrect and even incomplete. If you have corrections and share with me i will be appreciate. +NiceShaper has good scalability on routers that forward traffic for up to more or less half thousand of hosts although there are notices about successful working for even thousand of hosts. In bigger networks hash tables should be used. Unfortunately, hash tables are unsupported so far.

    Installation

    -Compilation and installation dependencies are: c++ compiler from gcc package, C and C++ standard libraries, and make utility. Unpacked package have to be compiled with omitted ./configure, because NiceShaper is Linux only software. +Compilation dependencies are c++ compiler from gcc package, C and C++ standard libraries, and make utility. Unpacked package has to be compiled omitting configure step because NiceShaper is Linux only software, thus compilation procedure is simplified.
    -$ bunzip2 niceshaper-%{wersja}.tar.bz2
    -$ tar xf niceshaper-%{wersja}.tar
    -$ cd niceshaper-%{wersja}
    +$ bunzip2 niceshaper-%{version}.tar.bz2
    +$ tar xf niceshaper-%{version}.tar
    +$ cd niceshaper-%{version}
    $ make
    $ su
    # make install
    -Make install command copies the compiled binary to the /usr/local/bin directory. The binary path may be changed using BINDIR environment variable. Make install command creates important directories: /etc/niceshaper, /var/lib/niceshaper, and /usr/share/doc/niceshaper. Example configuration files are copied to the /etc/niceshaper directory. If configuration files are found there then the actual files are copied with "-dist" postfix. The documentation and the rest of package content is copied to /usr/share/doc/niceshaper. +Make install command creates all needed directories (/etc/niceshaper, /var/lib/niceshaper, and /usr/share/doc/niceshaper). It copies the compiled binary to the /usr/local/bin directory. However, the binary path may be changed using BINDIR environment variable. Example configuration files are copied to the /etc/niceshaper directory. If configuration files are already found, in target location, then files are copied with "-dist" postfix. The documentation and the rest of package content is copied to /usr/share/doc/niceshaper.

    Configuration

    -

    Configuration files syntax.

    +

    Configuration files syntax

    -Common and required configuration files are /etc/niceshaper/config.conf and /etc/niceshaper/class.conf. +Required configuration files are config.conf and class.conf placed in /etc/niceshaper directory.
    - include file path - used in these files can include next ones. This directive accepts absolute and relative paths (by default to /etc/niceshaper/). -
    - -There are a few different syntax types for directives: - -
    - Syntax type #1) directive value - It is directive with one value only, e.g.: + include file path - Used in these files allows including next one. This directive accepts absolute (with starting slash char) and relative paths (by default to /etc/niceshaper/).
    -
    - rate 128kB/s -
    +Configuration consists the directives and the parameters which order is free and syntax is shown below:
    - Syntax type #2) directive value [value] - It is directive with one or number of values separated with whitespaces, e.g.: + parameter value [value] - Parameter with one or number of values separated with white spaces, for example:
    - mark-on-ifaces eth0 eth1 +
      +
    • ceil 5Mb/s
      • +
    • run dl ul
      • +
    - Syntax type #3) directive parameter value [parameter value] - It is directive with one or number of parameter-value pairs, e.g.: + directive parameter value [parameter value] - It's a directive with one or number of parameter-value pairs, for example:
    - status file /var/www/niceshaper/status.txt unit kB/s file-mode 644 + section speed 20Mb/s shape 19Mb/s
    -Order of above directives in a scope does not matter. -

    -When NiceShaper is starting, configuration parser splits type #2 and #3 directives into separated lines, so if you prefer you can write these directives also like that: +Configuration parser splits values or parameter-value pairs into a separated lines, so depending on own preferences these examples can be written in another way:

      -
    • mark-on-ifaces eth0
      • -
    • mark-on-ifaces eth1
      • -
    • status file /var/www/niceshaper/status.txt
      • -
    • status unit kB/s
      • -
    • status file-mode 644
      • +
    • ceil 5Mb/s
      • +
    • run dl
      • +
    • run ul
      • +
    • section speed 20Mb/s
      • +
    • section shape 19Mb/s
    -
    - Syntax type #4) match directive looks and works like type 3, but it's additional type. This is because you can not split it as it may change logic. Only order changing is permitted. -
    - -This is example of filter which classify packets with source address 10.10.10.5 and destination in network 192.168.0.0/29. - -
    - match srcip 10.10.10.5 dstip 192.168.0.0/29 -
    - -After split, gives 2 autonomous filters: - -
    -
      -
    • match srcip 10.10.10.5
      • -
    • match dstip 192.168.0.0/29
      • -
    -
    - -These two filter are properly in the mining of NiceShaper configuration syntax, but they are not identical with source filter. - -
    - Syntax type #5) Directives class is the most inflexible one, it can not be split and order changes at all, e.g.: -
    - -
    - class dl eth1 pc55 -
    -
    +Exceptions are: host, class, match, section headers, and macro headers. Their syntax is described later in documentation. -In addition to differences in syntax, directives are also divided according to the scope of operation, for directives of global section, directives of functional sections and directives of classes. When it comes to the directives of classes, all except the class header and filters can be placed in the functional sections configurations, providing default values for all classes included in the section. In the rest of the documentation, the three groups are clearly separated in groups. +In addition to differences in syntax, directives are also divided according to the scope of operation: directives of global section, directives of functional sections, and directives of classes file. When it comes to the directives and parameters of classes, all, except for the class header and filters, can be placed in the functional sections configurations, thus effectively providing default values for all classes contained in such section.

    -The basic units of capacity is b/s (bits per second), and B/s (Bytes per second). The prefixes are k (kilo) and M (mega). The suffix '/s' is not compulsory and the distinction between rate and the amount of transferred data is based on the context of use. Default unit of bandwidth is b/s (bits per second). +The basic units for rate and capacity is b/s (bits per second) and B/s (Bytes per second). The prefixes are k (kilo) and M (mega). The suffix '/s' is not compulsory and the distinction between rate and the amount of transferred data is based on the context of use. Default unit for bandwidth is b/s (bits per second).

    -NiceShaper gives you some special chars: Char hash "#" is using for comment out the rest of line. Comment block is "<# comment #>" and is using to affect some piece of configuration line. Commented configuration is useless. Char ";" means end of line, it gives you way to minimize length of config files by write a lot of semicolon separated directives in one line. +NiceShaper provides some special chars: Char "#" (hash) is using for comment out the rest of line. Comment block is "<# comment #>" and is using to affect some piece of configuration line. Commented configuration is useless. Char ";" means end of line, it gives you way to minimize length of configuration files by write a number of semicolon separated directives in one line.

    -Each change in configuration require to restart NiceShaper. +Each configuration modification requires NiceShaper to be restarted.

    -Remember, all examples are only examples and might not be optimal for you, although they are good point to start. +Remember, all examples are only examples and might not be optimal for you, although they are good point to start working with NiceShaper.

    Main configuration file - with example

    -Main configuration file /etc/niceshaper/config.conf is divided into sections. One called global, and minimum one, and in practice two or even more functional sections. Functional section is NiceShaper classes container configured for grouping classes and shape packages on appointed interfaces. Functional section reflect one direction of traffic so each the internet access uplink needs 2 functional sections to be fully controlled. Each functional section has got individual configuration, contained classes and defaults for these classes. Section can contain classes that works on various interfaces. Any number of functional sections may be placed on an interface. +Main configuration file, config.conf, is divided into the sections. First required section is named global. Additionally needed section, in practice two, and possibly even more, are functional sections. By design, functional section reflects one direction of traffic on one certain WAN connection connected to the router. So, each of WAN connections needs 2 functional sections in order to make complete traffic control. Each functional section includes it's own configuration, list of NiceShaper classes, and defaults for these classes. +

    +Functional section may contain classes that work on various interfaces. Classes contained in any number of functional sections may be placed on a certain interface (only if configured to shaping traffic that flows in the same direction).

    -An example of main configuration file: +Main configuration file example:

    @@ -227,196 +186,196 @@
    -

    Global section directives:

    +

    Global section directives and parameters:

    -

    Functional section directives:

    +

    Functional section directives and parameters:

    +
  • reload - How often adjust(reload) the classes contained within functional section. Constant monitoring and adjusting the classes is the main point of dynamic traffic shaping feature. The lower value, the faster reaction is obtained, but instead increased CPU load could be observed. NiceShaper, in order to help you find the best value, every hour for each running section generates and logs load reports. Effectively, high values transform dynamic traffic shaping into the almost static shaping, therefore values greater than 5s are not recommended. NiceShaper with high reload value can't react efficiently to quick traffic changes. Proper values are within the range of 0.1s to 60s with the step of 0.1s.
    • +
  • mode download|upload - It is a key parameter to ensure the proper cooperation with iptables. For all sections working in download mode a shared chain, ns_dwload, is created. This chain is targeted from the built-in POSTROUTING chain. Similarly, for the section of upload mode a chain called ns_upload is created with a source in the POSTROUTING chain as well (in version 1.2pre1 and earlier the PREROUTING chain was the source for ns_upload). Changing a built-in chain can be achieved using iptables directive with download-hook and upload-hook parameters, but is highly not recommended unless you are strongly advanced Administrator.
    • +i
    -You can place any classes parameters in functional section configuration, these becomes to be defaults for whole classes in a section. +Any of the classes parameters can be placed in functional section configuration, thus becomes to be defaults for all of classes contained in such section.

    Hosts and classes in NiceShaper

    -File /etc/niceshaper/class.conf holds list of hosts definitions and/or classes with their configuration. We can assume that NiceShaper class is an extended HTB class. Each NiceShaper class is built by a header, at least one filter and eventually additional options. Corresponding HTB class is created when NiceShaper notices activity and removed after a set period of inactivity. This gives optimal value of the rate parameter as only active HTB classes exists at the same time. Each packet leaving the interface is classified using filters to the first matching class. +File /etc/niceshaper/class.conf holds the list of hosts and/or classes definitions with their configuration. We can simply assume that NiceShaper class is an extension on top of HTB class. NiceShaper class has to be built by a header, at least one filter and possibly additional options. Corresponding HTB class is created when NiceShaper notices activity, afterwards removed after a certain period of inactivity. Effectively, only for active NiceShaper classes the HTB classes coexists at the same time what gives the optimal rate value of the HTB classes.

    -It is vitally important to define classes for whole traffic potentially observed on a link. If not there will appear traffic impossible to control, e.g, if not all hosts in local network will be assigned to classes, these will steal bandwidth from known classes. +Each packet which leaves the network interface is classified to the first matching class using filters. It is vitally important to define classes for entire traffic. If not, there occurs the traffic that is not monitored and not properly shaped. In the other words, if one or more of local LAN hosts is not assigned to the classes, these hosts falls beyond the section shape value. -

    Network host:

    +

    Hosts:

    -NiceShaper classes are advanced and flexible tool but simple directive named 'host' is in most cases sufficient and clear way to create fairly traffic shaping for all or most of common hosts in local network. It's the one of element thanks that NiceShaper offers such comfort. Host directive can give you a way to configure traffic shaping in NiceShaper without get to know classes. +NiceShaper classes are advanced and flexible tool, but simple directive named 'host' is in most cases sufficient and clear way to create the fairly traffic shaping for all of common hosts in local network. It's the one of elements thanks to which NiceShaper offers such comfort. Host directive gives a method to configure traffic shaping in NiceShaper just by write down the list of all LAN hosts' IP addresses and assign names to them.

    -To define host you need: list of section in which host must be placed paired with interface on which traffic shaping occurred, ip address and assigned name. Host directive may be placed into one or more of running sections. NiceShaper translate host directive to classes automatically for you. +To define host there is needed the list of sections in which host must be placed paired with interfaces on which traffic shaping occurred, followed by IP address, and assigned name. Host directive may be placed into one or more of running sections. Sections and interfaces values are just copied from auto-hosts directive, thus it's not needed to repeat them within each used host.

    -We can assume that host directive is some kind of NiceShaper macro. +It can be assumed that host directive is some kind of NiceShaper macro. NiceShaper automatically translates the host directive into the classes and filters.

    -NiceShaper host is placed in one line with syntax given below: +NiceShaper host definition is placed in one line, using the syntax as given below:

    - host section interface [section interface] ip name + host ip name
    -For example two host: +For example:
    These host directives will be translate, by NiceShaper configuration parser, to these classes:
    - +
    -NiceShaper inserts filter test dstip or srcip depending on section mode. -

    -Host are pointed out only by ip address. When you need another filtering tool or overwrite default parameters use classes instead of hosts. +Tests dstip or srcip are used depending on section mode.

    -Be carefully as above example of host pc11, which is included only in one section, is only example of how host directive syntax works. You should not leave any host traffic without control especially on upload. +Host is pointed out by IP address only. When another filtering tests or overwriting the default parameters are needed then classes have to be used instead of hosts. -

    Class structure

    +

    Class structure:

    -In the current version NiceShaper provides 4 types of classes. These are the standard class and a classes for special purposes: virtual, wrapper and do-not-shape. Last 2 types of classes are described in "Router's self generated traffic shaping". - -
    - -
    - -Class definition starts with a header and ends with a next class header or end of file. +NiceShaper, in the current version, provides 4 types of classes. These are the standard class and the classes for special purposes: virtual, wrapper, and do-not-shape. Virtual class is described in the "Virtual class type" and the last two types in the "Router's self generated traffic shaping".

    -Header of standard class and virtual class is as follows: +Class definition starts with the class header and ends with the next class header.

    - class|class-virtual section interface name + +

    + + Where: + +

    -Where: -

    -section - section to whose a class belongs.
    -interface - network interface on which a HTB class resides.
    -name - class name. -

    Each class must contains one or more filters:

    match test <test> [test <test>]
    -Filters classifies packets to classes. This applies to packets outgoing from class interface only (egress queue). Kernel filters are created when NiceShaper starts and, as you know after read of "Cooperation with iptables", iptables rules if needed. More than one test can be joined in one filter to be more specific on assign traffic to classes. Classes can contains many filters to aggregate more traffic. +More than one test can be joined in one filter to be more specific on assign traffic to classes. Classes can contain number of filters to allow aggregating into one class, more than one host's traffic or whatever pointed out by test. +

    +Filters applies to packets outgoing from the interface of class (egress shaping). Kernel filters are created when NiceShaper starts, but Iptables rules if needed as well.

    An example of the simplest class is as follows: @@ -427,7 +386,7 @@ -Everywhere in configuration you can use semi-colon instead of new line: +Semi-colon can be used instead of new line:

    -

    Class parameters:

    +

    Class directives and parameters:

    -Each option of classes can be placed in a functional section configuration, and becomes to be defaults to not repeat the same values for each class. Next if you wish these defaults can be override in classes with individual values. +Each parameter of classes can be placed into the functional section configuration, becomes to be defaults for each of contained classes. Next, if needed, these defaults can be override in certain classes with the individual values. -

    Basics filters tests:

    +

    Basics filtering tests:

    -srcip and dstip can match single ip address or network with subnet mask. In second case allows bits counter notation e.g. /24 or doted notation e.g. 255.255.255.0. -Mask can be non-continuous (e.g. 255.255.128.255) but in this case needs mark-on-ifaces because of it needs fw filter instead of u32. +Srcip and dstip can match single IP address or network subnet with the mask. In the second case the bits number notation (for example "/24") or dot-decimal notation (for example "255.255.255.0") is allowed. If FW kernel filter is used on the interface, via mark-on-ifaces parameter, mask can be non-continuous (for example 255.255.128.255).

    Example filters:

    - +

    Tests requiring packets marking on a class interface:

    -Iptables is equipped with a huge number of filters that are unfortunately not feasible using u32 filter. Therefore, these filters require packet marking by mark-on-ifaces directive. Each packet captured and marked by iptables can now easily be enqueued to the appropriate HTB class thanks to received mark value. +Iptables is equipped with a huge number of filters which are unfortunately not feasible using U32 kernel filter. Therefore, these filters require packets marking enabled using mark-on-ifaces directive. Then each packet captured and marked by iptables can be easily enqueued to the appropriate HTB class thanks to assigned mark value.

    CAUTION! Some of these filters may need additional kernel and iptables features compiled in.

    Macros of the class.conf file

    -Macros in a classes file are introduced to improve create of a lot of classes if they are similar. Macro iterates in a loop to duplicate specified area. Macro is built with a header, content and ending mark. Header is built by curly brackets that contains macro type and parameters. Content is ordinary class file area. In content there you may put some special chars, like $ (dollar) and % (percent). These chars are replaced by expected number or string. Macro ending mark is curly brackets that contains slash. +Macros in the classes file are introduced to improve creating of a lot of classes (or any of configuration directives) if they are similar. Macro iterates in a loop and duplicates specified area. Macro is built with a header, content and closing tag. Header is built by curly brackets that contains macro name and parameters. Content is an ordinary directives and parameters. In content you put some special chars: $ (dollar) and % (percent). These chars are replaced by expected number or string. Macro closing tag is the curly brackets which contain slash inside.

    -In actual NiceShape version are implemented 3 macro types - sequence, foreach-elem, foreach-pair. +NiceShaper shares 3 macro types: sequence, foreach-elem, and foreach-pair. -

    sequence macro:

    +

    Sequence macro:

    - {sequence from to} content {/} - sequence macro generates ascending numeric values in specified range. Values "from" and "to" must be positive integers, in range from 0 to 65535. Values are inserted in place of dollar special character. + {sequence from to} content {/} - Sequence macro generates the ascending numeric values in the specified range and applies these in the place of dollar special character. Values "from" and "to" have to be positive integers in the range of 0 to 65535.
    Example of sequence usage: @@ -571,7 +528,7 @@

    foreach-elem macro:

    - {foreach-elem list} content {/} - foreach-elem macro gets each element from given list and inserts it in place of dollar special char. List must contain numeric or text values separated by whitespaces. + {foreach-elem list} content {/} - Foreach-elem macro gets each element from the given, space separated, list of values and applies these in the place of dollar special char. Values can be numeric or text, separated by white spaces.
    Example of foreach-elem usage: @@ -601,7 +558,7 @@

    foreach-pair macro:

    - {foreach-pair list_of_pairs} content {/} - foreach-pair macro gets pairs of values from list. List must contain numeric or text values. Pairs are separated by commas, elements in pair are separated by whitespace. First element in pair is named a key and is inserted in place of percent char. Second element in pair is inserted in place of dollar. + {foreach-pair pair_of_values [,pair_of_values]} content {/} - Foreach-pair macro gets pairs of values from the list. Pairs are separated by commas, elements in the pair are separated by white space. First element in the pair is named a key and is applied in the place of percent char. Second element in the pair is inserted in the place of dollar. Values can be numeric or text.
    Example of foreach-pair usage: @@ -630,46 +587,45 @@

    Packet marking

    -Packet marking is a procedure to assign a virtual tag to a packet. Thanks to that it is still possible to identify packet sender after change the source address by SNAT (IP masquerade). The value is assigned by iptables, maintained by the Linux kernel and recognizable by iptables and the kernel FW filters. FW kernel filters classifies packets into a appropriate HTB class using test based on a virtual mark instead of a packet header. +Packets marking is a procedure of assigning the virtual tag value to packet. Thanks to that it's still possible to identify packet sender after the source address becomes changed by SNAT (Masquerading). Technically, the value is assigned by iptables, maintained by the Linux kernel and recognizable by iptables and the FW kernel filters. FW kernel filters classifies packets into the appropriate HTB classes using tests based on a virtual mark value instead of the packet header.

    -Marking packages mostly do not require patching iptables, iproute or kernel. NiceShaper manages all completely automatically so it's very easy to use this mechanism. Therefore, packet marking is a good way to avoid use of IMQ interfaces, which are comfortable but required patching the operating system important components. Marking allows you to comfortable control upload of your masqueraded computers. +Marking packets mostly do not require patching iptables, iproute, or kernel. NiceShaper manages all completely automatically, so it's very easy to use this mechanism. Therefore, packet marking is a good way to avoid using the IMQ interfaces, which are comfortable but required patching the operating system important components. Packets marking easily allows traffic shaping of packets uploaded from privately addressed local network.

    -So if packet marking on interface is turned on by mark-on-ifaces directive then NiceShaper for each class working on this interface will assign a unique mark value and U32 kernel filter on that interface will be replaced with FW. All this is done completely automatically. However if necessary it is possible to make intervention in this process thanks to a set-mark parameter. The value of set-mark must be unique for each class. +So, if packets marking on interface is turned on, by mark-on-ifaces directive, U32 kernel filter on that interface is replaced with FW and NiceShaper assigns a unique mark value for each class working on such interface. All is done completely automatically. However, if necessary, it's possible to make intervention in this process thanks to a set-mark parameter. The value of set-mark has to be unique for each class.

    -Iptables so NiceShaper too accepts mark values from 0 to 4294967295 (32bit unsigned value) written in decimal or hex started with 0x. +Accepted mark values are in the range of 0 to 4294967295 (32bit unsigned value) written using decimal or hex (prefixed with "0x"). -

    Usage of IMQ interfaces

    +

    Using IMQ interfaces

    NiceShaper supports IMQ compiled in AB mode (after NAT in PREROUTING chain and before NAT in POSTROUTING chain).

    -From the configuration of NiceShaper IMQ interfaces are the same way as physical ones. You can forget about their virtual, mostly, with complete freedom to mix classes on physical and IMQ interfaces. -

    -Niceshaper filters require to indicate a physical interface by out-iface test (or in-iface if iptables hook is changed to PREROUTING). +Within the configuration of NiceShaper, IMQ interfaces are handled almost the same way as physical interfaces. You can forget about their virtuality, with the exception of NiceShaper filters require to indicate a physical interface using out-iface test (or in-iface if iptables hook is changed to PREROUTING).

    Example snip from class.conf file:

    - +
    -NiceShaper automatically redirects traffic to IMQ interface. This behavior is configurable by iptables imq-autoredirect directive in global section. If you disable the automatic redirect to the IMQ you need to make it your self for NiceShaper by something like iptables ... -j IMQ --todev imqX. +NiceShaper automatically redirects traffic to IMQ interface. This behaviour is configurable by iptables imq-autoredirect directive in the global section. If, for some reason, you disable the automatic redirect to the IMQ interface, you need to make it yourself for NiceShaper using iptables ... -j IMQ --todev imqX.

    Triggers

    -Trigger is mechanism that allows you to automatically change the values of some class when a defined case occurs. In the current version NiceShaper two triggers types are implemented, alter and quota. +Triggers is the feature which automatically changes the values of indicated class parameters when defined condition occurs. In the current version NiceShaper two trigger types are implemented: alter and quota.

    Controllable parameters of the class:

    @@ -677,90 +633,93 @@
    -Triggers are class directives, most convenient way is to define them within the section, such as: +Triggers are class directives, thus most convenient way is defining them within the section. For example:
    -
    -The quota trigger have higher priority than the alter trigger if both have to be enabled. Triggers works only for standard-class. -Counters of trigger quota between running the program are stored in files section_name.quota in /var/lib/niceshaper directory. These files are updated when NiceShaper is stopping and during his work at 5 minutes intervals. If this file write fails, counters will be irretrievably lost! +The quota trigger is higher prioritized than the alter trigger if both are enabled. +

    +Counters of the quota trigger, while stopping NiceShaper, are stored in files named "section_name.quota" placed in the /var/lib/niceshaper directory. These files are updated each time while NiceShaper is stopped and also during work every 5 minutes. If file write fails, counters will be irretrievably lost! +

    +Triggers works only for standard-class. -

    Router's self generated traffic shaping

    +

    Shaping of router self generated traffic

    -Traffic generated by the router for his own needs is mostly negligibly small and often doesn't need to be shaped. But, in real world, router with Linux often serves file shares to the local network (simpler scenario) or even serves some network services to the internet (harder scenario). +Traffic generated by the router for his own needs is mostly negligibly small and often doesn't need to be shaped. But, in real world, router with Linux often serves file shares to the local network (simpler scenario) or even serves some network services on the internet (harder scenario).

    -Due to the fact that the traffic shaping takes place at the interface from which packets outgoings a machine, shaping incoming traffic (both on Internet and LAN side) is difficult and requires usage of IMQ interfaces. +Due to the fact that the traffic shaping takes place at the outbound interface of the machine, shaping incoming traffic (both on the Internet and the LAN side) is difficult and requires using of the IMQ interfaces.

    -To practically deal with this topic, the most convenient is the breakdown of the issues on four separate scenarios. +To practically deal with topic, the most convenient is splitting the description into the 4 separated scenarios.

    -In all scenarios it's required to add from-local or to-local test to filters. In combination with IMQ interfaces there is additional in-iface test requirement, eventually out-iface for outgoing traffic. It's important to let NiceShaper know physical interface at which packet arrives or leaves and to distinguish WAN side from LAN side traffic. +In all scenarios, it's required to use from-local or to-local test in filters. In case of using IMQ interfaces there is the additional in-iface test required for incoming traffic, or out-iface for outgoing traffic. It's important to let the NiceShaper know the physical interface at which packet arrives or leaves the router and also to distinguish WAN side from LAN side traffic.

    -Keep in mind that in most cases this purpose classes should be on the top of the list of all your classes. +Keep in mind that in most cases this special purpose classes should be put on the top of the list of classes.

    -Remind assumption that WAN is connected to eth0 and LAN is connected to eth1. Public address of router is 198.51.100.100, second public address for services is 198.51.100.101, private address is 192.168.0.1, and private network is 192.168.0.0/24. +To remind assumptions from documentation introduction, WAN is connected to eth0 and LAN is connected to eth1. Public address of the router is 198.51.100.100, second public address for services is 198.51.100.101, private address is 192.168.0.1, and private network is 192.168.0.0/24. -

    Traffic between the router and the local network (uplink bandwidth is not involved).

    +

    Traffic between the router and the local network (uplink throughput is not involved):

    -Traffic between a router and a local network requires to be not shaped or shaping should be minimised. This traffic shouldn't be shaped to the fact that local ethernet connection is mostly fast. Another big mistake would be accounting this traffic as uplink usage with the traffic generated by hosts. Classes in #1 and #2 scenarios (router with local network traffic related) have to be wrapper or do-not-shape types. +Traffic between a router and a local network is not expected to be shaped or shaping should be slight. This traffic shouldn't be shaped to the fact that the local Ethernet connection is mostly the fastest. Another big mistake could be accounting local traffic to the uplink traffic and summarizing into the Internet impacting traffic generated by hosts. Classes in number 1 and number 2 scenarios have to be wrapper or do-not-shape types.
    -Wrapper class and do-not-shape class doesn't belong to any section so their header is not the same as standard class has: +Wrapper class and do-not-shape class doesn't belong to any section so their header is not the same as the standard class header:
    class-wrapper|class-do-not-shape interface name
    -

    1. Router -> Localnet - Router sends traffic to the local network.

    +

    1. Router -> Localnet - Router sends the own generated traffic to the local network:

    -Traffic in this scenario is for example, local file or ftp server, local imap or pop3 server, etc. +Traffic in this scenario is, for example: local file sharing server, FTP server, local IMAP, or POP3 servers, etc.

    -Using do-not-shape type class - traffic is local so you do not want to shaping and accounting: +Using do-not-shape type class - traffic is local so you do not want to shape and account:

    -

    2. Router <- Localnet - Router gets traffic from the local network.

    +

    2. Router <- Localnet - Router is the final recipient of the traffic from the local network:

    -Traffic from the LAN to the router. For example, sending e-mail via the local SMTP server, place the files on a local file server, etc. +Traffic from the LAN to the router. For example, sending e-mails via the local SMTP server, place the files on local file sharing server, etc.

    Using do-not-shape type class - NiceShaper use POSTROUTING chain at iptables and doesn't use ingress shaping at kernel QOS. So, there is no requirement to create any do-not-shape type classes as traffic described in this scenario is uncontrolled in default configuration.

    @@ -798,22 +757,22 @@ -

    Traffic between the router and the internet (using uplink bandwidth).

    +

    Traffic between the router and the Internet (used uplink throughput):

    -Putting services on WAN side should be avoided. If SNAT and internet services on WAN side are used, services should use another public IP address. In this situation requirements of two public addresses is forced because there is no way to distinguish local from forwarded (NATed) traffic in the PREROUTING chain of mangle table. This distinguish is possible in INPUT chain (simplifying), but there is no way to redirect traffic to IMQ devices. +Putting Internet accessible services on the router should be avoided. If SNAT and Internet services on WAN side are used, services should use another public IP address. In this case, requirements of two public addresses is forced because there is no way to distinguish forwarded to local LAN and NATed traffic, in the PREROUTING chain of mangle table. This distinguish is possible in INPUT chain (simplifying), but it is not allowed to redirect traffic to the IMQ device from INPUT chain. -

    3. Router -> Internet - Router sends traffic to the internet.

    +

    3. Router -> Internet - Router sends the own generated traffic to the Internet:

    -Packets generated locally while sending to the internet e.g., mail service, web pages and other services on the router. +Packets generated locally while sending to the internet, for example mail service, web pages, and the other services on the router.

    -In this examples, two classes are created to separate traffic of two different services. +In this examples, two classes are created in order to separate traffic of two different services.

    @@ -827,11 +786,11 @@
    -Usage of class of mode upload and filter with a from-local test does not require extensive commentary here. Provide belief that traffic from the router to the internet is properly accounted. +Using class contained within upload mode section and filter with a from-local test don't require extensive commentary here. Provide belief that traffic from the router to the internet is properly accounted. -

    4. Internet => Router - downloading traffic from the internet to the router.

    +

    4. Internet => Router - Router is the final recipient of the traffic from the Internet:

    -This scenario occurs when a router retrieves traffic from the internet for e.g. the web pages retrieves by a proxy server or system updates that may steal a bandwidth from clients. +This scenario occurs when the router retrieves traffic from the internet, for example the web pages retrieves by a proxy server or system updates that may steal the bandwidth from clients.
    -Using a class at download mode section and a filter to-local don't require extensive commentary here too. +Using class contained within download mode section and a filter to-local don't require extensive commentary here too.

    -By default, the classes that belong to download mode puts their filters in the chain targeted from POSTROUTING where our packets will never arrive, so a to-local test creates a cloned rule in the PREROUTING chain. +By default, the classes that belong to download mode section put their filters in the chain targeted from POSTROUTING where our packets will never arrive, so a to-local test creates the cloned rule in the PREROUTING chain.

    Advanced topics

    Cooperation with iptables

    -In some cases NiceShaper uses iptables. In that case it creates rules in mangle table on starting and flushes them on stopping. You should avoid this cases whenever possible because rules for many NiceShaper classes generates additional system load. If at least one NiceShaper class in section required iptables rule, then rules are created for all NiceShaper classes in this section. And furthermore worst, iptables rules are created for each section with the same mode parameter value. +In some cases NiceShaper uses iptables. In such cases, creates rules in mangle table when starting and flushes them when stopping. You should avoid this cases whenever possible, because rules for many NiceShaper classes generates additional system load. If at least one NiceShaper class in section required iptables rule, then rules are created for all NiceShaper classes in this section. What's furthermore worst, iptables rules are created for each section with the same mode parameter value.

    -To be precise, iptables rules are required and created for the following cases: +To be precise, iptables rules are required and created in the following cases:

    -Reading any of the chains not held more than 10 times a second. If a section is reloaded again before this time it will use the previous cached values. -

    -Until version 1.0 NiceShaper used iptables rules as fundamental. Rules was always created and NiceShaper looked for activity and accounted traffic. From version 1.2pre1 iptables stopped to be fundamental. +Reading any of the chains don't occur more often than 10 times per second. If a section is reloaded again, before expire time, the previously cached values will be used.

    Cooperation with HTB

    -NiceShaper creates QOS framework on each controlled interface. This framework looks like on diagram below. It contains HTB classes, queuing algorithms and kernel filters. HTB classes creates tree hierarchy by which traffic is propagated as you see. +NiceShaper creates QOS framework based on HTB on each controlled interface. This framework is built like described on diagram below. It contains HTB classes, queuing algorithms and kernel filters. HTB classes build the tree hierarchy where traffic is propagated, from the top to the bottom, as you see.

    -NiceShaper doesn't use the tc program. It communicates, using a Netlink protocol, directly with the Linux kernel (the code that provides this functionality is partially based on iproute code). It's the most efficient way to manage QOS objects. +NiceShaper almost doesn't use the tc program, but communicates directly with the Linux kernel using Netlink protocol (the code that provides this functionality is partially based on iproute code). It's the most efficient way to manage QOS objects.

    @@ -877,24 +834,55 @@
    -On bottom level of tree there are HTB classes which becomes to be parents for NiceShaper classes defined by you. These HTB classes share full speed of interface but do not borrow from each other. +On the bottom level of tree there are HTB classes which are the parents for NiceShaper classes which you define in configuration. These HTB classes share the full speed of the interface, but do not borrow from each other.

    These special HTB classes act as:

    -1) Each section which works on an interface gets HTB class with throughput equal to section speed parameter value. This HTB class becomes parent for each child HTB classes within that section. One child HTB class is automatically created as Waiting Room. Traffic classified by filters in first step is directing into Waiting Room. In second step when section is reloading filter are modified to directing traffic to newly created HTB class. After some time of inactivity this newly created HTB class is removed and kernel filter directing traffic to Waiting Room again. This time of inactivity is set by hold parameter which has 30 seconds default. In this solution in one time there are only us much HTB classes as activated NiceShaper classes, thanks for that HTB class rate parameter value is optimal. +1) Each section which works on an interface gets the own HTB class with throughput equal to the section speed value. This HTB class becomes parent for each of child HTB class contained within such section. One of child HTB classes is automatically created and named "Waiting Room". Traffic classified by filters in first step is directing into the Waiting Room. In second step, when section is reloading, filter are modified in order to directing traffic to newly created HTB class. After defined time of inactivity this newly created HTB class is removed and kernel filter directs traffic to Waiting Room again. This time of inactivity is set by hold parameter which default is 30 seconds. In this solution in one time there are only us much HTB classes as activated NiceShaper classes, thanks to that HTB class rate parameter value is optimal.

    -2) This HTB class as parent for do-not-shape and wrapper classes is created when on interface works one of or both of specified class types. In case of do-not-shape class it is true only with iface do-not-shape-method safe option. This HTB class throughput is calculated from iface speed minus sections speed minus fallback class. +2) This HTB class as parent for do-not-shape and wrapper classes is created if on the interface works one of or both of specified class types. In case of do-not-shape class it is true only with iface do-not-shape-method safe parameter. This HTB class throughput is calculated from iface speed minus sections speed minus fallback class.

    -3) HTB fallback class works with whole traffic outgoing from interface and unclassified by filters. In proper configuration this class should be idle, otherwise you should looking for lack in defined classes and filters. +3) HTB fallback class works with whole traffic outgoing from the interface and unclassified by filters. In proper configuration this class should be idle all the time, otherwise you should looking for lacks in defined classes and filters. + +

    Virtual class type

    + +Virtual is the next type of classes in NiceShaper. Header of such class: + +
    + class-virtual section interface name - Class of this type has entries in iptables, but not in HTB. Virtual class is not the tool for any traffic shaping, it's useful for measuring and reporting of utilization of observed traffic. Class of this type belongs to the section, but observed traffic is ignored by the dynamic traffic shaping algorithm. Because of this feature, packets matched by virtual class need to be then matched by standard class which finally catches such traffic. +
    + +Example of such classes: +
    + +
    + +Example of the niceshaper status command results: + +
    + 
    +dl                              ceil -      last-ceil (   last-traffic )
+^g70-v-http^                                          (        424kb/s )
+^g70-v-https^                                         (        608kb/s )
+g70                         5000kb/s -       5000kb/s (       1032kb/s )
+
    +
    diff -Nru niceshaper-1.2.3/docs/en/index.html niceshaper-1.2.4/docs/en/index.html --- niceshaper-1.2.3/docs/en/index.html 2016-06-04 20:09:43.000000000 +0000 +++ niceshaper-1.2.4/docs/en/index.html 2016-12-27 21:55:03.000000000 +0000 @@ -23,21 +23,21 @@

    NiceShaper's description

    -NiceShaper is a program working in a Linux router environment. It uses a proven HTB QOS algorithm. It provides dynamic traffic shaping which is more effective than traditional, static shaping. By constantly monitoring packets flowing through the router in response to changing load dynamically adjusts the bandwidth of acting classes to a level enabling the fullest possible usage of a internet access. At the same time does not allow for creation of congestion, ensuring complete convenience of interactive services. +NiceShaper is the program developed for Linux router environment. It works in user space on top of standard Linux QOS implementation and iptables. By default, a proven HTB algorithm is used for the root, inner, and leaf classes, SFQ packets scheduling algorithm is the default queuing discipline (qdisc) contained within each of leaf classes, U32 and FW are used as the packets classifiers. NiceShaper provides dynamic traffic shaping approach which is more effective than traditional shaping with static rates. While constantly monitoring the traffic flowing through the router, in response to the changing load, dynamically adjusts the rate and ceil parameters values of enabled HTB classes to the values which enable the fullest possible utilization of Internet connection throughput.

    -NiceShaper protects each class which use reasonable amount of bandwidth and takes care of overall download when upload is close to stop up. +NiceShaper protects each host which uses reasonable amount of shared throughput while watching over the configured optimal utilization of Internet connection. Therefore, at the asymmetric Internet connection, takes care of download when upload is close to stop up (and vice versa). NiceShaper doesn't allow for creation of congestions, thus ensures the comfort of using interactive services as well.

    -NiceShaper offers: +Besides of mentioned basis, NiceShaper offers:

    @@ -49,7 +49,7 @@ -Graph is taken from network where too many users use upload demand p2p software, what may kill upload bandwidth and finally destroy download performance. Using NiceShaper on router with ADSL line gives the best download and upload intake. In the same time each user can surfing with high speed, playing online games, work with ssh, and go on. NiceShaper all the time cares of downloading or uploading files does not disturb interactive. +Graph is taken from the network where too many users use upload demand P2P software, what may kills the upload throughput and finally destroys download performance as well. Using NiceShaper on the router, connected through the asymmetric xDSL line, enables the best download and upload utilization. In the same time each user can surf with the comfortable throughput available, playing online games, use interactive services, and so on. NiceShaper all the time cares of that downloading or uploading the big amount of data don't disturb the interactive.

    [2016-03-06]

    diff -Nru niceshaper-1.2.3/docs/en/install_editors.html niceshaper-1.2.4/docs/en/install_editors.html --- niceshaper-1.2.3/docs/en/install_editors.html 2016-06-04 20:09:43.000000000 +0000 +++ niceshaper-1.2.4/docs/en/install_editors.html 2016-12-27 21:55:03.000000000 +0000 @@ -11,35 +11,43 @@

    Install syntax highlighting in popular text editors

    -Niceshaper package comes with syntax files included. +NiceShaper package includes a syntax highlighting files for popular text editors.

    -Vim and Midnight Commander are supported. But Vim support is better ahead. It even fulfills some syntax check. +Vim and Midnight Commander (mcedit) are supported. However, Vim support is much better, even enables some syntax checking.

    Vim

    -Vim have two methods to install syntax highlighting. Globally and per user. Making per user installation let assume that root user are the only one who needs this feature. -

    -Copy editors/vim/niceshaper.vim file to /root/.vim/syntax directory. Create this directory if does not exist. -

    -To file /root/.vimrc append: -

    -:syntax on
    -autocmd BufNewFile,BufRead *niceshaper*/*.conf set filetype=niceshaper -

    -Syntax highlighting will work for all files with .conf extension placed in niceshaper directory or subdirectory. +Installation of syntax highlighting for root user can be achieved by copying the editors/vim/niceshaper.vim file into the /root/.vim/syntax/ directory. If the /root/.vim/syntax/ directory doesn't exist, it needs to be created manually. Then in order to register a new configuration file type, there is needed to add the following rules into the /root/.vimrc file: -

    Midnight Commander

    +
    + :syntax on
    + autocmd BufNewFile,BufRead *niceshaper*/*.conf set filetype=niceshaper +
    -Copy file editors/mc/niceshaper.syntax to proper directory of Midnight Commander. For example in Debian it is /usr/share/mc/syntax. -

    -There is a Syntax file, in which you need to append 2 lines: -

    -file .\*/etc/niceshaper.\*\\.conf$ NiceShaper\sconfiguration ^#\sNiceShaper
    -include niceshaper.syntax +Thanks to this rules, syntax highlighting is enabled for all of text files with the ".conf" extension, placed within the path that contains the "niceshaper" word. + + +

    Midnight Commander - mcedit

    + +In the case of mcedit, there is disadvantage of syntax highlighting installation for the user, thus shared installation is recommended. Shared installation can be achieved by copying the editors/mc/niceshaper.syntax into the /usr/share/mc/syntax/ directory.

    -Syntax highlighting will work for files with .conf extension placed in /etc/niceshaper directory or subdirectory. It will also work for files contains '# NiceShaper' in first line. +Finally, the Syntax file contained within this directory needs to be appended with the following rules: + +

    + file .\*niceshaper.\*\\.conf$ NiceShaper\sconfiguration ^#\sNiceShaper
    + include niceshaper.syntax +
    + +New rules have to be inserted before the last rules which already exist at the end of the Syntax file. It means before: + +
    + file .\* unknown
    + include unknown.syntax +
    + +Syntax highlighting works for files with the ".conf" extension placed within the path that contains the "niceshaper" word or contains '# NiceShaper' at first line.

    -After Midnight Commander upgrade you may need to redo this installation. +Warning! After upgrade of the Midnight Commander package, it could be needed to redo this installation. diff -Nru niceshaper-1.2.3/docs/pl/changelog.html niceshaper-1.2.4/docs/pl/changelog.html --- niceshaper-1.2.3/docs/pl/changelog.html 2016-06-04 20:09:43.000000000 +0000 +++ niceshaper-1.2.4/docs/pl/changelog.html 2016-12-27 21:55:03.000000000 +0000 @@ -11,6 +11,31 @@

    Lista zmian

    +

    [NiceShaper 1.2.4 2016-12-26]

    + +Ważne zmiany i nowe funkcjonalności: + +
    + +
    + +Usunięte błędy i problemy: + +
    + +
    +

    [NiceShaper 1.2.3 2016-05-27]

    diff -Nru niceshaper-1.2.3/docs/pl/documentation.html niceshaper-1.2.4/docs/pl/documentation.html --- niceshaper-1.2.3/docs/pl/documentation.html 2016-06-04 20:09:43.000000000 +0000 +++ niceshaper-1.2.4/docs/pl/documentation.html 2016-12-27 21:55:03.000000000 +0000 @@ -33,6 +33,7 @@ @@ -43,7 +44,7 @@ Celem działania NiceShapera jest umożliwienie optymalnego wykorzystania łącza internetowego oraz uproszczenie konfiguracji, złożonego zagadnienia jakim jest kształtowanie ruchu sieciowego w Linuksie. Projektując rozwiązania staram się by były one elastyczne, intuicyjne i przejrzyste, by upraszczały to co niepotrzebnie skomplikowane, ale też udostępniały możliwość konfigurowania tego, nad czym warto mieć kontrolę.

    -Możliwe jest wstępne stworzenie dobrze działającego podziału łącza, bez zapoznania się z tą dokumentacją, używając dołączonych przykładowych plików konfiguracyjnych, pod warunkiem posiadania w miarę solidnych podstaw z zakresu działania sieci. Należy mieć jednak świadomość, że po przyjrzeniu się dołączonym przykładowym plikom konfiguracyjnym i pierwszym uruchomieniu NiceShapera, wypada zapoznać się z niniejszą dokumentacją, w przeciwnym wypadku może nie udać się stworzyć optymalnie działającego podziału łącza. NiceShaper bardzo się stara, ale nie jest w stanie odgadnąć wszystkich Twoich intencji, dlatego wiedza z zakresu sieci oraz systemu Linux jest ważna. Nie należy się jednak zrażać czytając dokumentację, gdyż wykracza ona poza minimum potrzebne do uruchomienia podstawowego podziału łącza. W końcu NiceShaper ma ułatwiać to co w HTB trudne, ale jednocześnie dostarczać dodatkowych możliwości. +Możliwe jest wstępne stworzenie dobrze działającego podziału łącza, bez zapoznania się z tą dokumentacją, używając dołączonych przykładowych plików konfiguracyjnych, pod warunkiem posiadania w miarę solidnych podstaw z zakresu działania sieci. Należy mieć jednak świadomość, że po przyjrzeniu się dołączonym przykładowym plikom konfiguracyjnym i pierwszym udanym uruchomieniu NiceShapera, warto zapoznać się z niniejszą dokumentacją by lepiej poznać dostępne funkcjonalności programu. NiceShaper bardzo się stara, ale nie jest w stanie odgadnąć wszystkich Twoich intencji, dlatego wiedza z zakresu sieci oraz systemu Linux jest ważna. Nie należy się jednak zrażać czytając dokumentację, gdyż wykracza ona poza minimum potrzebne do uruchomienia podstawowego podziału łącza. W końcu NiceShaper ma ułatwiać to co w HTB trudne, ale jednocześnie dostarczać dodatkowych możliwości.

    W minimalnej konfiguracji niezbędny jest router z systemem Linux z programem iptables i wkompilowanymi w kernel: kolejką HTB, algorytmem kolejkowania SFQ oraz filtrem kernela U32.

    @@ -91,93 +92,57 @@ Wymagane podstawowe pliki konfiguracji to /etc/niceshaper/config.conf oraz /etc/niceshaper/class.conf.

    - include file ścieżka - dyrektywa include użyta w tych plikach pozwala włączać kolejne. Dyrektywa include obsługuje ścieżki absolutne (z rozpoczynającym znakiem slash) oraz relatywne do katalogu konfiguracyjnego (domyślnie /etc/niceshaper). + include file ścieżka - Dyrektywa include użyta w tych plikach pozwala włączać kolejne. Dyrektywa include obsługuje ścieżki absolutne (z rozpoczynającym znakiem slash) oraz relatywne do katalogu konfiguracyjnego (domyślnie /etc/niceshaper).
    -Konfiguracja składa się z kilku typów dyrektyw, różniących się składnią: +Sama konfiguracja składa się z dyrektyw i parametrów, których kolejność nie jest istotna a składnia to:
    - Typ 1) parametr wartość - czyli parametr z przypisaną mu wartością, np.: + parametr wartość [wartość] - Czyli parametr z przypisaną mu jedną lub listą, rozdzielonych białymi znakami, wartości, np.:
    - rate 128kB/s -
    - -
    - Typ 2) parametr wartość [wartość] - czyli parametr z przypisanymi mu rozdzielonymi białymi znakami (spacja, tabulator) wartościami, np.: -
    - -
    - mark-on-ifaces eth0 eth1 -
    - -
    - Typ 3) dyrektywa parametr wartość [parametr wartość] - czyli dyrektywa z listą parametrów i wartości, wymienionych parami, np.: -
    - -
    - status file /var/www/niceshaper/status.txt unit kB/s file-mode 644 -
    - -W przypadku wszystkich trzech wymienionych powyżej typów, kolejność dyrektyw i parametrów nie jest istotna. -

    -W przypadku typów 2 i 3, czyli list, parser konfiguracji automatycznie rozbija podane wartości lub pary parametrów z wartościami. Więc w ramach własnych preferencji, powyższe przykłady, można także zapisać następująco: - -

      -
    • mark-on-ifaces eth0
      • -
    • mark-on-ifaces eth1
      • -
    • status file /var/www/niceshaper/status.txt
      • -
    • status unit kB/s
      • -
    • status file-mode 644
      • +
    • ceil 5Mb/s
      • +
    • run dl ul
    - Typ 4) Dyrektywa match to składniowo dyrektywa typu 3, jednak nie można jej rozbijać na osobne linie. Dozwolona jest wyłącznie dowolność w kolejności par parametrów. Rozbicie parametrów zburzyło by sens i spójność filtra. + dyrektywa parametr wartość [parametr wartość] - Czyli dyrektywa z listą parametrów i wartości, wymienionych parami, np.:
    -Przykładowy, poniżej, filtr klasyfikujący pakiety z adresem źródłowym 10.10.10.5 oraz jednocześnie docelowym z zakresu sieci 192.168.0.0/29: -
    - match srcip 10.10.10.5 dstip 192.168.0.0/29 + section speed 20Mb/s shape 19Mb/s
    - -Po rozbiciu tworzy 2 niezależne filtry: -
    -
      -
    • match srcip 10.10.10.5
      • -
    • match dstip 192.168.0.0/29
      • -
    -
    - -Same w sobie są one poprawne, ale nie są tożsame z filtrem wyjściowym. +Parser konfiguracji automatycznie rozbija podane wartości lub pary parametrów z wartościami. Stąd w ramach własnych preferencji, powyższe przykłady, można również zapisać następująco: -
    - Typ 5) Zapis dyrektywy class nie podlega żadnej elastyczności. np.: -
    -
    - class dl eth1 pc55 -
    - +
    -Poza różnicami składniowymi dyrektywy dzielą się ze względu na zasięg funkcjonowania na: dyrektywy sekcji global, dyrektywy sekcji funkcjonalnych oraz dyrektywy klas. Jeśli chodzi o dyrektywy klas, wszystkie poza nagłówkiem klasy oraz filtrem mogą zostać umieszczone w konfiguracjach sekcji funkcjonalnych. Tym samym dostarczając wartości domyślnych dla wszystkich klas wchodzących w skład takiej sekcji.W dalszej części dokumentacji te trzy grupy są wyraźnie rozdzielone. +Wyjątkami od powyższych zasad są dyrektywy: host, class, match, nagłówki sekcji oraz nagłówki makr. Ich składnia opisana jest w dalszej części konfiguracji. +

    +Poza różnicami składniowymi dyrektywy dzielą się, ze względu na zasięg funkcjonowania, na: dyrektywy sekcji global, dyrektywy sekcji funkcjonalnych oraz dyrektywy klas. Jeśli chodzi o dyrektywy klas, wszystkie poza nagłówkiem oraz filtrem mogą zostać umieszczone w konfiguracjach sekcji funkcjonalnych, w efekcie dostarczając wartości domyślnych dla wszystkich klas wchodzących w skład takiej sekcji.

    -Podstawowe jednostki przepustowości to b/s - bit na sekundę, oraz B/s - bajt na sekundę. Poprawne przedrostki to k-kilo oraz M-mega. Dopisek '/s' nie jest obowiązkowy a rozróżnienie między przepustowością a ilością przesłanych danych odbywa się na podstawie kontekstu. Jednostką domyślną przepustowości jest b/s (bit na sekundę). +Podstawowe jednostki przepustowości to b/s (bit na sekundę), oraz B/s (bajt na sekundę). Poprawne przedrostki to k (kilo) oraz M (Mega). Dopisek '/s' nie jest obowiązkowy a rozróżnienie między przepustowością a ilością przesłanych danych odbywa się na podstawie kontekstu. Jednostką domyślną przepustowości jest b/s (bit na sekundę).

    NiceShaper udostępnia kilka znaków specjalnych. Znak "#" jest komentarzem i odnosi się do reszty linii występującej za nim. Znaki "<# komentarz #>" również tworzą komentarz, z tą różnicą że stosuje się je w parze a obejmują dowolny wycinek linii konfiguracyjnej. Oczywiście zakomentowana część konfiguracji nie jest brana pod uwagę. Kolejny znak specjalny, znak średnika, zastępuje przejście do nowej linii konfiguracji, pozwala zminimalizować długość pliku konfiguracyjnego klas, czasem pozytywnie a czasem negatywnie wpływa na czytelność.

    -Wszystkie zmiany w konfiguracji wymagają zrestartowania programu. +Każda zmiana konfiguracji wymagają zrestartowania programu.

    -Wszystkie konfiguracje dostarczone z pakietem są tylko przykładami i nie są optymalne dla każdej sieci - choć są dobrym materiałem wyjściowym do wdrożenia programu. +Wszystkie konfiguracje dostarczone z pakietem są tylko przykładami i nie są optymalne dla każdej sieci - choć są dobrym materiałem wyjściowym do poznania programu.

    Główny plik konfiguracyjny, na przykładzie

    -Domyślnie głównym plikiem konfiguracyjnym jest plik /etc/niceshaper/config.conf. Jest on podzielony na sekcje. Do prawidłowego działania niezbędna jest jedna i tylko jednak sekcja o nazwie global, zawierająca główną konfiguracje programu oraz minimum jedna a w praktyce dwie lub nawet więcej sekcji funkcjonalnych. Sekcja funkcjonalna jest kontenerem grupującym klasy NiceShapera. Z reguły odzwierciedla jeden z kierunków przepływu ruchu przez łącze internetowe, tak więc każde łącze obsługiwane jest przez minimum dwie sekcje. Każda sekcja dysponuje własną konfiguracją, własną listą klas oraz parametrami domyślnymi dla tych klas. W skład sekcji wchodzić mogą klasy pracujące na różnych interfejsach, a na każdym interfejsie pracować mogą, klasy wchodzące w skład różnych sekcji. +Domyślnie głównym plikiem konfiguracyjnym jest plik /etc/niceshaper/config.conf. Jest on podzielony na sekcje. Do prawidłowego działania niezbędna jest, zawierająca główną konfiguracje programu, sekcja o nazwie global. Dodatkowo minimum jedna a w praktyce dwie, lub nawet więcej, sekcje funkcjonalne. Sekcja funkcjonalna, z reguły, odzwierciedla jeden z kierunków przepływu ruchu przez łącze internetowe, podłączone do obsługiwanego routera. Podsumowując, każde łącze obsługiwane jest przez minimum dwie sekcje funkcjonalne. Każda sekcja dysponuje własną konfiguracją, listą klas NiceShapera oraz parametrami domyślnymi dla tych klas. W skład sekcji wchodzić mogą klasy pracujące na różnych interfejsach, a na każdym interfejsie pracować mogą, klasy wchodzące w skład różnych sekcji (o ile obsługują ten sam kierunek ruchu).

    Przykładowa zawartość głównego pliku konfiguracyjnego: @@ -188,13 +153,14 @@

    @@ -229,111 +195,112 @@ -

    Opcje sekcji global:

    +

    Dyrektywy i parametry sekcji global:

    -

    Opcje sekcji funkcjonalnych:

    +

    Dyrektywy i parametry sekcji funkcjonalnych:

    @@ -347,24 +314,24 @@

    Hosty:

    -Klasy są zaawansowanym oraz bardzo elastycznym narzędziem. Jednak to dyrektywa host jest najczęściej wystarczającym i jednocześnie bardzo przyjaznym oraz przejrzystym sposobem, na stworzenie sprawiedliwego podziału łącza dla wszystkich lub większości standardowych użytkowników sieci. Jest to jeden z tych elementów, dzięki którym konfiguracja podziału łącza w NiceShaperze jest tak wygodna. Hosty umożliwiają wygodną konfigurację podziału łącza, nawet bez zapoznawania się z klasami! +Klasy są zaawansowanym oraz bardzo elastycznym narzędziem. Jednak to dyrektywa host jest najczęściej wystarczającym i jednocześnie bardzo przyjaznym oraz przejrzystym sposobem, na stworzenie sprawiedliwego podziału łącza dla wszystkich lub większości standardowych użytkowników sieci. Jest to jeden z tych elementów, dzięki którym konfiguracja podziału łącza w NiceShaperze jest tak wygodna. Dyrektywa host umożliwia wygodną konfigurację podziału łącza, nawet bez zapoznawania się z klasami, po prostu spisując listę adresów IP wszystkich hostów obsługiwanych w sieci lokalnej i przydzielając im dowolne nazwy!

    -Do zdefiniowania hosta potrzebne są: lista sekcji w których ma on być umieszczony wraz z interfejsami na których ma następować kształtowanie ruchu, adres ip oraz nadana nazwa. Host może należeć do dowolnych z uruchomionych sekcji, ale musi należeć przynajmniej do jednej. NiceShaper sam zajmie się przetłumaczeniem dyrektywy host na odpowiednie klasy i filtry. +Do zdefiniowania hosta potrzebne są: lista sekcji w których ma on być umieszczony wraz z interfejsami na których ma następować kształtowanie ruchu, adres IP oraz nadana nazwa. Host może należeć do dowolnych z uruchomionych sekcji, ale musi należeć przynajmniej do jednej. Sekcje oraz interfejsy kopiowane są wprost z dyrektywy auto-hosts, więc nie ma potrzeby każdorazowego powtarzania tej listy.

    -Można przyjąć, że dyrektywa host to funkcjonalnie pewnego rodzaju makro NiceShapera. +Można przyjąć, że dyrektywa host to funkcjonalnie pewnego rodzaju makro NiceShapera. NiceShaper sam zajmie się przetłumaczeniem dyrektywy host na odpowiednie klasy i filtry.

    Definicja hosta mieści się zawsze w jednej linii. Składniowo wygląda następująco:

    - host sekcja interfejs [sekcja interfejs] ip nazwa + host ip nazwa
    Przykładowo:
    @@ -376,42 +343,39 @@
  • match dstip 192.168.0.10
  • class ul eth0 pc10
  • match srcip 192.168.0.10
    • +

  • class dl eth1 pc11
  • match dstip 192.168.0.11
    • +
  • class ul eth0 pc11
    • +
  • match srcip 192.168.0.11
    • NiceShaper wstawia do filtrów test dstip lub srcip, zależnie od trybu sekcji.

    Host wskazywany jest wyłącznie za pomocą adresu IP. Tam gdzie potrzebne są dodatkowe możliwości filtrowania lub nadpisywania parametrów domyślnych, tam wkraczają klasy. -

    -UWAGA: Powyższy przykład hosta pc11, przypisanego tylko do jednej sekcji, ma za zadanie wyłącznie naświetlenie składni dyrektywy. Nigdy nie należy pozostawiać żadnego z hostów w sieci bez kontroli, szczególnie w zakresie uploadu.

    Budowa klasy:

    -W aktualnej wersji NiceShaper udostępnia 4 typy klas. Są to klasa standardowa oraz klasy o specjalnym przeznaczeniu: virtual, wrapper oraz do-not-shape. Przy czym ostatnie dwa typy opisane zostały w rozdziale "Jak traktować ruch z i do routera". - -
    - -
    - -Definicję klasy rozpoczyna nagłówek klasy a kończy nagłówek kolejnej. +W aktualnej wersji NiceShaper udostępnia 4 typy klas. Są to klasa standardowa oraz klasy o specjalnym przeznaczeniu: virtual, wrapper oraz do-not-shape. Przy czym klasy typu virtual opisane zostały w rozdziale "Klasy typu virtual" a ostatnie dwie w rozdziale "Jak traktować ruch z i do routera".

    -Nagłówek klas typów standardowego i virtual wygląda następująco: +Definicję klasy rozpoczyna nagłówek klasy a kończy nagłówek kolejnej:

    - class|class-virtual sekcja interfejs nazwa -
    + +

    -Gdzie: -

    -sekcja - sekcja w skład której wchodzi klasa.
    -interfejs - interfejs na którym realizowane jest kolejkowanie klasy za pomocą HTB.
    -nazwa - nazwa klasy, wyświetlana m.in. przez status. -

    + Gdzie: + +

    + + Obowiązkowym parametrem ciała klasy jest filtr:
    @@ -437,36 +401,36 @@
    -

    Parametry klas:

    +

    Dyrektywy i parametry klas:

    @@ -478,15 +442,15 @@
      -
    • proto tcp|udp|icmp - protokół.
      • -
    • srcip - adres źródłowy.
      • -
    • dstip - adres docelowy.
      • -
    • srcport|sport - port źródłowy. Wymaga wskazania protokołu tcp lub udp.
      • -
    • dstport|dport - port docelowy. Wymaga wskazania protokołu tcp lub udp.
      • -
    • from-local - ułatwia kontrolę pakietów wysyłanych przez router. Zastępuje srcip a wskazany adres, musi być poprawnie skonfigurowany na jednym z interfejsów routera. W sytuacji kiedy iptables hook sekcji to PREROUTING lub interfejs klasy to interfejs pracujący w trybie upload, zostaje utworzony duplikat filtra bezpośrednio w łańcuchu POSTROUTING z celem w łańcuchu sekcji. Zabieg ten jest niezbędny, by pakiety wychodzące z routera pojawiły się w łańcuchu sekcji.
      • -
    • to-local - umożliwia kontrolę pakietów odbieranych przez router. Działa analogicznie jak from-local z tą różnicą, że zastępuje test dstip a dodatkowe dowiązanie, tworzone jest w łańcuchu PREROUTING, jeśli iptables hook sekcji to POSTROUTING lub interfejs klasy to interfejs pracujący w trybie download.
      • -
    • out-iface - interfejs którym pakiet opuszcza router. Do reguł iptables zostaje dodany podany interfejs, jako interfejs wychodzący. Ma zastosowanie wyłącznie wtedy gdy interfejsem klasy jest interfejs IMQ, wskazując interfejs fizyczny.
      • -
    • in-iface - interfejs którym pakiet wchodzi do routera. Do reguł iptables zostaje dodany podany interfejs, jako interfejs wchodzący. Analogicznie, ma zastosowanie wyłącznie wtedy gdy interfejsem klasy jest interfejs IMQ.
      • +
    • proto tcp|udp|icmp - Protokół.
      • +
    • srcip - Adres źródłowy.
      • +
    • dstip - Adres docelowy.
      • +
    • srcport|sport - Port źródłowy. Wymaga wskazania protokołu tcp lub udp.
      • +
    • dstport|dport - Port docelowy. Wymaga wskazania protokołu tcp lub udp.
      • +
    • from-local - Ułatwia kontrolę pakietów wysyłanych przez router. Zastępuje srcip a wskazany adres, musi być poprawnie skonfigurowany na jednym z interfejsów routera. W sytuacji kiedy iptables hook sekcji to PREROUTING lub interfejs klasy to interfejs pracujący w trybie upload, zostaje utworzony duplikat filtra bezpośrednio w łańcuchu POSTROUTING z celem w łańcuchu sekcji. Zabieg ten jest niezbędny, by pakiety wychodzące z routera pojawiły się w łańcuchu sekcji.
      • +
    • to-local - Umożliwia kontrolę pakietów odbieranych przez router. Działa analogicznie jak from-local z tą różnicą, że zastępuje test dstip a dodatkowe dowiązanie, tworzone jest w łańcuchu PREROUTING, jeśli iptables hook sekcji to POSTROUTING lub interfejs klasy to interfejs pracujący w trybie download.
      • +
    • out-iface - Interfejs którym pakiet opuszcza router. Do reguł iptables zostaje dodany podany interfejs, jako interfejs wychodzący. Ma zastosowanie wyłącznie wtedy gdy interfejsem klasy jest interfejs IMQ, wskazując interfejs fizyczny.
      • +
    • in-iface - Interfejs którym pakiet wchodzi do routera. Do reguł iptables zostaje dodany podany interfejs, jako interfejs wchodzący. Analogicznie, ma zastosowanie wyłącznie wtedy gdy interfejsem klasy jest interfejs IMQ.
    @@ -496,8 +460,8 @@
      -
    • match srcip 192.168.0.77 - pakiety pochodzące z adresu 192.168.0.77.
      • -
    • match srcip 217.74.65.69 srcport 110 dstip 192.168.0.0/29 proto tcp - poczta pobierana z interii do podsieci 192.168.0.0/29.
      • +
    • match srcip 192.168.0.77 - Pakiety pochodzące z adresu 192.168.0.77.
      • +
    • match srcip 192.0.2.1 srcport 110 dstip 192.168.0.0/29 proto tcp - Poczta pobierana z 192.0.2.1 do podsieci 192.168.0.0/29.
    @@ -509,26 +473,26 @@
      -
    • not-srcip - adres źródłowy inny niż podany.
      • -
    • not-dstip - adres docelowy inny niż podany.
      • -
    • not-srcport|not-sport - port źródłowy inny niż podany (należy wskazać protokół tcp lub udp).
      • -
    • not-dstport|not-dport - port docelowy inny niż podany (należy wskazać protokół tcp lub udp).
      • -
    • length - długość pakietu w bajtach, np. 500, :500( od 0 do 500), 500: (500 i większe), 128:500 (128 do 500).
      • -
    • state new|established|related|invalid|untracked - stan pakietu:
      • -
    • -
        -
      • new - pakiet rozpoczyna nowe połączenie.
        • -
      • established - pakiet należy do nawiązanego połączenia.
        • -
      • related - pakiet rozpoczynający nowe połączenie jednak powiązany z istniejącą konwersacją (np. transfer danych po ftp).
        • -
      • invalid - pakiet nie może zostać rozpoznany.
        • -
      • untracked - pakiet nie należący do śledzonego połączenia.
        • +
      • not-srcip - Adres źródłowy inny niż podany.
        • +
      • not-dstip - Adres docelowy inny niż podany.
        • +
      • not-srcport|not-sport - Port źródłowy inny niż podany (należy wskazać protokół tcp lub udp).
        • +
      • not-dstport|not-dport - Port docelowy inny niż podany (należy wskazać protokół tcp lub udp).
        • +
      • length - Długość pakietu w bajtach, np. 500, :500( od 0 do 500), 500: (500 i większe), 128:500 (128 do 500).
        • +
      • state new|established|related|invalid|untracked - Stan pakietu:
        • +
      • +
          +
        • new - Pakiet rozpoczyna nowe połączenie.
          • +
        • established - Pakiet należy do nawiązanego połączenia.
          • +
        • related - Pakiet rozpoczynający nowe połączenie jednak powiązany z istniejącą konwersacją (np. transfer danych po ftp).
          • +
        • invalid - Pakiet nie może zostać rozpoznany.
          • +
        • untracked - Pakiet nie należący do śledzonego połączenia.
        • -
      • tos - wartość pola TOS pakietu.
        • +
      • tos - Wartość pola TOS pakietu.
      • ttl - TTL pakietu równe podanej wartości.
      • ttl-lower - TTL pakietu mniejsze od podanej wartości.
      • ttl-greater - TTL pakietu większe od podanej wartości.
        • -
      • mark - dopasowuje pakiety, oznaczone przez iptables, podaną wartością wirtualnego znacznika. Praktycznie w każdym przypadku znacznik pakietu zostanie zamieniony na inny, przypisany automatycznie każdej klasie, o ile nie zostanie użyta by temu zapobiec, opcja set-mark klasy. Dodatkowo warto wiedzieć, że podana wartość znacznika będzie chroniona, co oznacza, że NiceShaper nie przydzieli jej żadnej innej klasie.
        • +
      • mark - Dopasowuje pakiety, oznaczone przez iptables, podaną wartością wirtualnego znacznika. Praktycznie w każdym przypadku znacznik pakietu zostanie zamieniony na inny, przypisany automatycznie każdej klasie, o ile nie zostanie użyta by temu zapobiec, opcja set-mark klasy. Dodatkowo warto wiedzieć, że podana wartość znacznika będzie chroniona, co oznacza, że NiceShaper nie przydzieli jej żadnej innej klasie.
    @@ -650,10 +614,10 @@
      -
    • class ul imq5 pc5.82
      • -
    • match srcip 10.10.5.82 out-iface eth0
      • -
    • class ul imq5 pc5.83
      • -
    • match srcip 10.10.5.83 out-iface eth0
      • +
    • class ul imq0 pc10
      • +
    • match srcip 192.168.0.10 out-iface eth0
      • +
    • class ul imq0 pc11
      • +
    • match srcip 192.168.0.11 out-iface eth0
    @@ -668,9 +632,9 @@
      -
    • low - minimalny przydział pasma (domyślnie: 8b/s)
      • -
    • ceil - maksymalny przydział pasma (domyślnie równe section shape).
      • -
    • rate - stały przydział pasma.
      • +
    • low - Minimalny przydział pasma. Domyślnie: 8b/s
      • +
    • ceil - Maksymalny przydział pasma. Domyślnie równe section shape.
      • +
    • rate - Stały przydział pasma.
    @@ -681,19 +645,19 @@
  • alter {low|ceil|rate} {time-period} - Wyzwalacz alter w określonym przedziale czasu podmienia wartości zdefiniowanych parametrów, np. w celu zwiększenia przydziałów w porze nocnej.
    • -
    • time-period gg:mm-gg:mm - określa czas w którym wyzwalacz jest aktywny, np. 22:00-05:00. Domyślnie: no - wyzwalacz wyłączony.
      • +
    • time-period gg:mm-gg:mm - Określa czas w którym wyzwalacz jest aktywny, np. 22:00-05:00. Domyślnie: no - wyzwalacz wyłączony.
  • quota {low|ceil|rate} {day|week|month} [reset-hour] [reset-wday] [reset-mday] - Wyzwalacz quota umożliwia zmianę wybranych parametrów klasy po zliczeniu przez klasę określonej ilości przesłanych danych, np. w celu dalszego ograniczenia pasma. Wyzwalacz ten zaopatrzony jest w 3 liczniki: dzienny, tygodniowy oraz miesięczny, zadziała zawsze gdy jeden lub więcej liczników przekroczy ustalony limit.
    • -
    • day - limit dzienny przesłanych danych. Wartość minimalna to 1MB, obsługiwane są jednostki MB, GB oraz TB. Domyślnie: no - wyłączony licznik dzienny quoty.
      • -
    • week - limit tygodniowy, analogicznie jak powyżej.
      • -
    • month - limit miesięczny, analogicznie jak powyżej.
      • -
    • reset-hour gg:mm - czas w którym następuje zresetowanie licznika quoty dziennej i przywrócenie oryginalnych parametrów jeśli zmieniono i liczniki tygodniowy oraz miesięczny nie zostały przekroczone. Domyślnie 00:00.
      • -
    • reset-wday 1 do 7 - jak dla quoty dziennej, określa dzień w którym następuje wyzerowanie licznika quoty tygodniowej. 1 to poniedziałek, 2 to wtorek, itd. aż do 7 czyli niedzieli. Reset następuje przy pierwszym przeładowaniu sekcji wskazanego dnia. Domyślnie: 1 czyli poniedziałek.
      • -
    • reset-mday 1 do 31 - analogicznie jak dla quoty tygodniowej. Jeśli wartość wykracza poza ostatni dzień miesiąca, np. 31 w miesiącu 30 dniowym, reset następuje ostatniego dnia takiego miesiąca. Domyślnie: 1.
      • +
    • day - Limit dzienny przesłanych danych. Wartość minimalna to 1MB, obsługiwane są jednostki MB, GB oraz TB. Domyślnie: no - wyłączony licznik dzienny quoty.
      • +
    • week - Limit tygodniowy, analogicznie jak powyżej.
      • +
    • month - Limit miesięczny, analogicznie jak powyżej.
      • +
    • reset-hour gg:mm - Czas w którym następuje zresetowanie licznika quoty dziennej i przywrócenie oryginalnych parametrów jeśli zmieniono i liczniki tygodniowy oraz miesięczny nie zostały przekroczone. Domyślnie 00:00.
      • +
    • reset-wday 1 do 7 - Jak dla quoty dziennej, określa dzień w którym następuje wyzerowanie licznika quoty tygodniowej. 1 to poniedziałek, 2 to wtorek, itd. aż do 7 czyli niedzieli. Reset następuje przy pierwszym przeładowaniu sekcji wskazanego dnia. Domyślnie: 1 czyli poniedziałek.
      • +
    • reset-mday 1 do 31 - Analogicznie jak dla quoty tygodniowej. Jeśli wartość wykracza poza ostatni dzień miesiąca, np. 31 w miesiącu 30 dniowym, reset następuje ostatniego dnia takiego miesiąca. Domyślnie: 1.
    • @@ -733,7 +697,7 @@

    Przypomnijmy, że łącze internetowe podłączone jest do interfejsu eth0, sieć LAN do eth1. Adres publiczny routera to 198.51.100.100, a dodatkowy adres dla usług to 198.51.100.101, adres prywatny to 192.168.0.1, a adresacja sieci lokalnej to 192.168.0.0/24. -

    Wymiana ruchu routera z siecią lokalną (nie angażuje pasma łącza).

    +

    Wymiana ruchu routera z siecią lokalną (nie angażuje pasma łącza):

      @@ -757,7 +721,7 @@ class-wrapper|class-do-not-shape interfejs nazwa
    -

    1. Router -> Localnet - Router wysyła dane do sieci lokalnej.

    +

    1. Router -> Localnet - Router wysyła dane do sieci lokalnej:

    Ruch opisywany w tym scenariuszu to, np. lokalny serwer plików samba lub ftp, serwery poczty imap czy pop3 itp.

    @@ -782,7 +746,7 @@

    -

    2. Router <- Localnet - Router odbiera dane z sieci lokalnej.

    +

    2. Router <- Localnet - Router odbiera dane z sieci lokalnej:

    Ruch z sieci lokalnej do routera. Np. umieszczanie zasobów na lokalnym serwerze plików, wysyłanie poczty za pomocą lokalnego serwera smtp itp.

    @@ -799,7 +763,7 @@ -

    Wymiana ruchu routera z internetem (angażuje pasmo łącza).

    +

    Wymiana ruchu routera z internetem (angażuje pasmo łącza):

    @@ -895,6 +859,37 @@

    3) Kolejka awaryjna przejmuje cały niesklasyfikowany ruch wychodzący z interfejsu. By podział łącza mógł działać poprawnie do tej kolejki nie powinno nigdy nic wpadać. Jeśli ten warunek nie zostaje spełniony, należy odszukać braki w zdefiniowanych klasach i filtrach. Aż do wersji 1.0pre3 cały niesklasyfikowany przez utworzone filtry ruch, zostawał skolejkowany z pełną prędkością interfejsu. Utrudniało to poprawne działanie podziału. Jednak przywrócenie tego sposobu zachowania jest możliwe, umożliwia je odpowiednia opcja dyrektywy iface. W tym przypadku awaryjna kolejka HTB w ogóle nie zostanie utworzona. Od wersji 1.0pre4 niesklasyfikowany ruch próbujący opuścić kontrolowany interfejs musi przejść przez kolejkę awaryjną o bardzo niskiej przepustowości. +

    Klasy typu virtual

    + +Kolejnym typem klas NiceShapera to klasa virtual. Nagłówek tej klasy wygląda następująco: + +
    + class-virtual sekcja interfejs nazwa - Klasa tego typu wprowadzona zostaje wyłącznie do przestrzeni iptables, w HTB nie istnieje. Klasa virtual nie służy do kontrolowania ruchu, służy do mierzenia i raportowania wykorzystania obserwowanego pasma. Klasa tego typu należy do sekcji, jednak ruch sklasyfikowany do tej klasy jest pomijany przez algorytm dynamicznego podziału, co oznacza, że dopasowane pakiety muszą ostatecznie zostać sklasyfikowane do klasy standardowej. +
    + +Przykładowo: + +
    + +
    + +Przykładowy rezultat komendy niceshaper status: + +
    + 
    +dl                              ceil -      last-ceil (   last-traffic )
+^g70-v-http^                                          (        424kb/s )
+^g70-v-https^                                         (        608kb/s )
+g70                         5000kb/s -       5000kb/s (       1032kb/s )
+
    +
    diff -Nru niceshaper-1.2.3/docs/pl/index.html niceshaper-1.2.4/docs/pl/index.html --- niceshaper-1.2.3/docs/pl/index.html 2016-06-04 20:09:43.000000000 +0000 +++ niceshaper-1.2.4/docs/pl/index.html 2016-12-27 21:55:03.000000000 +0000 @@ -23,20 +23,20 @@

    NiceShaper

    -NiceShaper jest programem działającym w środowisku routera z systemem operacyjnym Linux. Wykorzystuje sprawdzony algorytm podziału łącza HTB. Umożliwia efektywniejsze dzielenie pasma, niż to, utworzone poprzez przydzielenie użytkownikom sieci stałych przepustowości. Dodatkowo upraszcza to, co w kształtowaniu ruchu sieciowego w Linuksie skomplikowane, a także wprowadza wiele dodatkowych funkcjonalności. NiceShaper stale monitorując ilości danych przepływających przez router, w odpowiedzi na zmieniające się obciążenie i charakterystykę ruchu generowanego przez użytkowników, dynamicznie dostosowuje przepustowość działających klas, do poziomu umożliwiającego możliwie najpełniejsze wykorzystanie łącza. Jednocześnie nie dopuszczając do powstawania przeciążeń, gwarantuje wygodę użytkowania usług interaktywnych. +NiceShaper jest programem działającym w środowisku routera z systemem operacyjnym Linux. Pracuje w przestrzeni użytkownika, wykorzystując standardową Linuksową implementację QOS oraz iptables. Domyślnie, wykorzystuje sprawdzony algorytm podziału łącza HTB w roli klas pośrednich (root, inner) oraz terminujących(leaf). Dyscyplina kolejkowania (qdisc) SFQ jest domyślnym algorytmem kolejkowania dołączanym do klas terminujacych. Filtry U32 oraz FW umożliwiają klasyfikowanie pakietów do klas. NiceShaper udostępnia podejście dynamicznego podziału łącza, które, jest efektywniejsze niż tradycyjne dzielenie pasma z przypisanymi, użytkownikom sieci, stałymi przepustościami. NiceShaper stale monitorując ilości danych przepływających przez router, w odpowiedzi na zmieniające się obciążenie i charakterystykę ruchu generowanego przez użytkowników, dynamicznie dostosowuje wartości parametrów rate oraz ceil utworzonych klas HTB do poziomu umożliwiającego możliwie najpełniejsze wykorzystanie łącza.

    -NiceShape chroni pasma użytkowników, rozsądnie korzystających z przepustowości łącza i dba o to, by nie dopuścić do nadmiernego wysycenia pasma uploadu blokującego łącze. +NiceShape chroni pasma użytkowników, rozsądnie korzystających z przepustowości łącza i dba o to, by utrzymywać wysycenie pasma na skonfigurowanym optymalnym poziomie. Tak więc, w przypadku asymentrycznego dostępu do internetu, dba o to by nie dopuścić do nadmiernego wysycenia pasma uploadu co w efekcie mogło by doprowadzić do zablokowania downloadu (i odwrotnie). Nie dopuszczając do powstawania przeciążeń, gwarantuje również wygodę użytkowania usług interaktywnych.

    Ponadto NiceShaper oferuje:

    @@ -48,8 +48,8 @@ Wykres MRTG - -Wykres został zarejestrowany w sieci, w której użytkownicy bardzo intensywnie wykorzystują oprogramowanie P2P, wymagające udostępniania zasobów. Jest to zabójcze dla łącz asymetrycznych charakteryzujących się małym pasmem wychodzącym. Na zielono download, upload - niebieska linia, obydwa kierunki przepływu danych praktycznie zawsze w pełni obciążone. Mimo to każdy użytkownik ma zagwarantowane wygodne surfowanie, pracę lub grę online. Konfiguracja statyczna praktycznie wyklucza tak skuteczne wysycenie pasma w obydwu kierunkach, wymuszając kompromis pomiędzy stopniem wykorzystania łącza a wygodą użytkowania usług interaktywnych. + +Wykres został zarejestrowany w sieci, w której użytkownicy bardzo intensywnie wykorzystują oprogramowanie P2P wymagające, udostępniania zasobów. Jest to zabójcze dla łącz asymetrycznych charakteryzujących się małym pasmem wychodzącym. Na zielono download, upload - niebieska linia, obydwa kierunki przepływu danych praktycznie zawsze w pełni obciążone. Mimo to każdy użytkownik ma zagwarantowane wygodne surfowanie, pracę lub grę online. Konfiguracja statyczna praktycznie wyklucza tak skuteczne wysycenie pasma w obydwu kierunkach, wymuszając dużo wiekszy kompromis pomiędzy stopniem wykorzystania łącza a wygodą użytkowania usług interaktywnych.

    [2016-03-06]

    diff -Nru niceshaper-1.2.3/docs/pl/install_editors.html niceshaper-1.2.4/docs/pl/install_editors.html --- niceshaper-1.2.3/docs/pl/install_editors.html 2016-06-04 20:09:43.000000000 +0000 +++ niceshaper-1.2.4/docs/pl/install_editors.html 2016-12-27 21:55:03.000000000 +0000 @@ -11,33 +11,42 @@

    Konfiguracja podświetlania składni plików konfiguracyjnych

    -W pakiecie NiceShapera dostarczane są pliki umożliwiające, uruchomienie, obsługi podświetlania składni edytowanych plików konfiguracyjnych. +W pakiecie NiceShapera dostarczane są, pliki umożliwiające uruchomienie obsługi podświetlania składni edytowanych plików konfiguracyjnych.

    -Obsługiwane są edytory Vim oraz Midnight Commander, przy czym podświetlanie dla Vima jest dużo lepszej jakości - umożliwia nawet podstawową kontrolę składni. +Obsługiwane są edytory Vim oraz Midnight Commander (mcedit). Przy czym podświetlanie dla Vima jest dużo lepszej jakości, umożliwia nawet podstawową kontrolę składni.

    Vim

    -Vim umożliwia instalację podświetlania składni na 2 sposoby, globalnie oraz na koncie użytkownika. W drugim przypadku nie zachodzi ryzyko nadpisania konfiguracji, podczas aktualizacji pakietu Vim i jest to sposób zalecany. -

    -Przyjmując założenie że instalacja ma dotyczyć wyłącznie użytkownika root, plik editors/vim/niceshaper.vim skopiować należy do katalogu /root/.vim/syntax/. Katalog ten jeśli nie istnieje należy wcześniej utworzyć. Do pliku /root/.vimrc dodać należy wpisy: -

    -:syntax on
    -autocmd BufNewFile,BufRead *niceshaper*/*.conf set filetype=niceshaper -

    -Tak skonstruowana regułka zapewni że podświetlanie składni będzie dotyczyło wszystkich plików z rozszerzeniem .conf, których ścieżka dostępu zawiera 'niceshaper'. +Instalacja plików podświetlania składni dla użytkownika root, sprowadza się do skopiowania pliku editors/vim/niceshaper.vim do katalogu /root/.vim/syntax/. Jeśli katalog /root/.vim/syntax/ nie istnieje należy go wcześniej utworzyć. Następnie, w celu zarejestrowania nowego typu pliku, do /root/.vimrc należy dodać wpisy: -

    Midnight Commander

    +
    + :syntax on
    + autocmd BufNewFile,BufRead *niceshaper*/*.conf set filetype=niceshaper +
    -Plik editors/mc/niceshaper.syntax skopiować należy do odpowiedniego katalogu Midnight Commandera. Dla przykładu w Debianie i wielu innych dystrybucjach jest to /usr/share/mc/syntax. -

    -Znajdujący się w tym samym katalogu plik Syntax należy uzupełnić o wpis: -

    -file .\*/etc/niceshaper.\*\\.conf$ NiceShaper\sconfiguration ^#\sNiceShaper
    -include niceshaper.syntax +Tak skonstruowana regułka zapewni, że podświetlanie składni dotyczyło będzie, wszystkich plików z rozszerzeniem .conf których ścieżka dostępu zawiera słowo "niceshaper". + +

    Midnight Commander - mcedit

    + +W przypadku mcedit instalacja na koncie użytkownika posiada pewną wadę, przez którą zalecana jest instalacja na poziomie konfiguracji globalnej. Instalacja sprowadza się do skopiowania pliku editors/mc/niceshaper.syntax do katalogu /usr/share/mc/syntax/.

    -Podświetlanie składni dotyczyć będzie plików z rozszerzeniem '.conf', których ścieżka dostępu zawiera '/etc/niceshaper'. Ta reguła będzie również dotyczyła plików w których pierwsza linia zaczyna się od '# NiceShaper'. +Znajdujący się w tym samym katalogu plik Syntax, należy uzupełnić o poniższy wpis: + +

    + file .\*niceshaper.\*\\.conf$ NiceShaper\sconfiguration ^#\sNiceShaper
    + include niceshaper.syntax +
    + +Umieszczając go przed ostatnim znajdującym się w nim wpisem, czyli przed: + +
    + file .\* unknown
    + include unknown.syntax +
    + +Podświetlanie składni dotyczyć będzie plików z rozszerzeniem ".conf", których ścieżka dostępu zawiera słowo "niceshaper" lub pierwsza linia zaczyna się od "# NiceShaper".

    -Uwaga!! Po aktualizacji pakietu mc może zaistnieć potrzeba ponownego dodania wpisu do pliki Syntax. +Uwaga! Po aktualizacji pakietu mc może zaistnieć potrzeba ponownego dodania wpisu do pliki Syntax. diff -Nru niceshaper-1.2.3/editors/mc/niceshaper.syntax niceshaper-1.2.4/editors/mc/niceshaper.syntax --- niceshaper-1.2.3/editors/mc/niceshaper.syntax 2016-06-04 20:09:43.000000000 +0000 +++ niceshaper-1.2.4/editors/mc/niceshaper.syntax 2016-12-27 21:55:03.000000000 +0000 @@ -11,10 +11,11 @@ keyword whole set-mark red keyword whole strict red - keyword whole debug red keyword whole mark-on-ifaces red + keyword whole local-subnets red keyword whole run red keyword whole fallback red + keyword whole debug red keyword whole log red keyword whole users red @@ -28,7 +29,9 @@ keyword whole iptables red keyword whole alter red keyword whole quota red - keyword whole iface\-\[abcdefghijklmnopqrstuvwxyz0123456789\] red + keyword whole auto-hosts red + keyword whole iface\-\[abcdefghijklmnopqrstuvwxyz0123456789+.:-\] red + keyword whole auto-hosts red keyword whole host red keyword whole class red diff -Nru niceshaper-1.2.3/editors/vim/niceshaper.vim niceshaper-1.2.4/editors/vim/niceshaper.vim --- niceshaper-1.2.3/editors/vim/niceshaper.vim 2016-06-04 20:09:43.000000000 +0000 +++ niceshaper-1.2.4/editors/vim/niceshaper.vim 2016-12-27 21:55:03.000000000 +0000 @@ -78,14 +78,13 @@ syn match nsValue contained "full-throttle" syn match nsValue contained "fallback-class" syn match nsValue contained "do-not-control" -syn region nsDirectiveRegion matchgroup=nsDirective start=/^\s*\(log\|users\|status\|stats\|listen\|section\|htb\|sfq\|esfq\|iptables\|alter\|quota\|iface-[a-z0-9+.]\+\)\s\+/ end=/$/ contains=@nsType4List keepend +syn region nsDirectiveRegion matchgroup=nsDirective start=/^\s*\(log\|users\|status\|stats\|listen\|section\|htb\|sfq\|esfq\|iptables\|alter\|quota\|iface-[a-z0-9+.:\-]\+\|auto-hosts\)\s\+/ end=/$/ contains=@nsType4List keepend " Directives 'host' and 'class-*' syn region nsDirectiveRegion matchgroup=nsDirective start=/^\s*\(host\|class\|class-virtual\|class-wrapper\|class-do-not-shape\)\s\+/ end=/$/ contains=nsComment,nsLoopMacroSymbol keepend " Directives 'match' and 'include' syn keyword nsParameter contained proto srcip dstip sport srcport dport dstport -syn keyword nsParameter contained length state tos ttl mark syn keyword nsParameter contained file syn match nsParameter contained "in-iface" syn match nsParameter contained "out-iface" @@ -101,6 +100,7 @@ syn match nsParameter contained "ttl-greater" syn match nsParameter contained "set-mark" syn keyword nsValue contained new established related invalid untracked +syn keyword nsParameter contained length state tos ttl mark syn region nsDirectiveRegion matchgroup=nsDirective start=/^\s*\(match\|include\)\s\+/ end=/$/ contains=@nsType4List keepend " Default highlighting diff -Nru niceshaper-1.2.3/etc/niceshaper/class.conf niceshaper-1.2.4/etc/niceshaper/class.conf --- niceshaper-1.2.3/etc/niceshaper/class.conf 2016-06-04 20:09:43.000000000 +0000 +++ niceshaper-1.2.4/etc/niceshaper/class.conf 2016-12-27 21:55:03.000000000 +0000 @@ -1,68 +1,83 @@ # NiceShaper second configuration file. +############## +# Introduction +### + +# This file contains definitions of hosts or classes (or both). # -# Assumptions and introduction +# Are you asking which one is better to use (hosts or classes)? +# Host directive is introduced for simplicity and is sufficient in most cases. +# Use hosts if you do not need advancements and flexibility of classes. + +########################## +# Configuration with hosts +### + +# To make the host directive works, at first it's needed to complete the +# auto-hosts directive placed within the config.conf file in the global section. +# Then, it's completely enough to just write down the list of all LAN hosts. # +# The syntax of host directive is: -# This file contains definitions of hosts or classes or both. +# host ip_address assigned_name -# Are you asking which one is better to use? -# Host directive is introduced for simplicity and is sufficient in most cases. -# It's worth to know that NiceShaper translates the host directive -# into the classes, internally, because host is some kind of NiceShaper's macro. -# Use hosts if you do not need advancement and flexibility of classes. +# For example: -# The host directive is one-liner, the syntax is: -# -# host section interface [section interface] ip-address name -# -# The host directive is made of list of pairs which contains -# section and interface to work on (run egress shaping on), -# IP address of host on last but one position, assigned name on last one. -# -# The standard class syntax is: +# host 192.168.0.10 pc10 +# host 192.168.0.11 pc11 +# host 192.168.0.12 pc12 +# etc... + +# It's all what is needed to start working with NiceShaper. # -# class section interface name -# match test value [test value] +# It's worth to know that NiceShaper, internally, translates the host directive +# into the NiceShaper classes. It means that host is just macro of NiceShaper. # +# After first run, if you want to know more (e.g. learn classes), +# read the rest of this configuration file and then the documentation as well. +# Hosts and classes are fully explained +# in the "Hosts and classes in NiceShaper" part of documentation. -# It's fully explained in "Hosts and classes in NiceShaper" -# part of documentation. +############################ +# Configuration with classes +### +# Firstly, it's suggested to create the class responsible for manage the traffic +# that is outgoing locally from the router machine to the local LAN network. +# It's obvious that the local traffic shouldn't be shaped or might be slightly shaped +# but the observed traffic shouldn't be accounted like the traffic from the Internet is. +# Use class-wrapper instead of class-do-not-shape if some limiting is expected. +# Traffic of both of these class types is not monitored by dynamic shaping algorithm. # -# Configuration -# +# Uncomment two lines below (class header and filter), +# fix LAN interface, IP address of the router and LAN network subnet. -# Firstly, it's suggested to create the class responsible for manage traffic -# that outgoings from this router machine to the local network. -# It's obvious that local traffic shouldn't be shaped or might be shaped at -# slightly limited speed. Use class-wrapper instead of class-do-not-shape if -# you want to slightly limit. -# -# You have to uncomment two lines below, fix LAN interface, and IP addresses. -# -#class-do-not-shape eth1 router-to-lan +# class-do-not-shape eth1 router-to-lan # match from-local 192.168.0.1 dstip 192.168.0.0/24 -# Then let's define each local network host. -# You have to uncomment the host directive(s), -# fix LAN interface of "dl" section, fix WAN interface of "ul" section, -# IP addresses, and assigned names. -# -#host dl eth1 ul eth0 192.168.0.10 pc10 -#host dl eth1 ul eth0 192.168.0.11 pc11 -#host dl eth1 ul eth0 192.168.0.12 pc12 -# -# and so on... - -# If you want to know how to get the same functionality using classes, -# look on these two classes below as these are -# functionally exactly the same as above for host called pc10. +# However, class for local traffic has to be placed at the beginning +# of classes list, thus needs to be moved into the beginning of this file +# if configuration approach with hosts is used. # -#class dl eth1 pc10 +# It's time to explain how to achieve the same functionality, +# as with host directive, using classes. +# +# The syntax of standard class and one required filter is: + +# class section interface assigned_name +# match test value [test value] + +# For example, the classes which fully substitute the host called pc10 (written above): + +# class dl eth1 pc10 # match dstip 192.168.0.10 -#class ul eth0 pc10 +# class ul eth0 pc10 # match srcip 192.168.0.10 -# Now add the rest of hosts or classes or both. +# Now add the rest of hosts or classes (or both), +# and then execute the niceshaper start command. +# +# Beware, each host in local network which generates the traffic has to be known for +# NiceShaper, otherwise the dynamic traffic shaping algorithm won't work properly! diff -Nru niceshaper-1.2.3/etc/niceshaper/config.conf niceshaper-1.2.4/etc/niceshaper/config.conf --- niceshaper-1.2.3/etc/niceshaper/config.conf 2016-06-04 20:09:43.000000000 +0000 +++ niceshaper-1.2.4/etc/niceshaper/config.conf 2016-12-27 21:55:03.000000000 +0000 @@ -1,86 +1,134 @@ # NiceShaper main configuration file. -# -# Assumptions and introduction -# - -# For purpose of example configuration files, it's assumed that, -# this (under configuration) router is equipped with two interfaces. -# The eth0 interface is WAN side, and eth1 interface is local LAN side. -# IP address assigned to eth1 interface is 192.168.0.1/24. - -# It's fundamental that egress shaping occurs on outgoing interface, so, -# shaping of download traffic has to be placed on eth1 interface. -# On the other hand, shaping of upload traffic has to be placed on eth0. -# This is because the downloaded packets incomes via eth0 interface -# and outgoes to the local network via eth1 interface (for above assumptions!). -# Respectively, the uploaded packets incomes from local network via eth1, -# and outgoes to the internet via eth0 interface. -# It's all valid for above assumptions and may be required to be adjusted! +############## +# Introduction +### + +# Let's adjust internet access parameters, below in config.conf file, +# and define the hosts or classes list in class.conf. +# Then execute the niceshaper start command. +# It's done! Just so simple to start using NiceShaper. +# Use the niceshaper status command to observe how it works. -# Full explanation in "Introduction and requirements" part of documentation. +############################## +# Assumptions and introduction +### +# For purpose of configuration example, +# It's assumed that the router is equipped with two interfaces: +# Eth0 - WAN side interface. +# Eth1 - LAN side interface, respectively. +# Assumed IP address assigned to eth1 interface is 192.168.0.1/24, +# thus a local LAN subnet is 192.168.0.0/24. # -# Configuration +# NiceShaper uses egress shaping approach for traffic shaping. +# Therefore, it's fundamental that classes which control the forwarded traffic +# have to be placed on the interface which is outbound for such traffic. +# So, in assumed environment, shaping of download traffic has to be +# placed on eth1, but shaping of upload traffic has to be placed on eth0. +# Why? Because, for above assumptions, downloaded packets incomes into the router +# via eth0 interface and then are sent to the local network via eth1 interface. +# It makes the eth1 the outbound interface for download. +# Explanation for opposite direction is analogical. # +# More explanations in the "Introduction and requirements" part of documentation. + +############### +# Configuration +### -# Configuration in this file is divided into the sections. +# Main configuration file is divided into the sections. +# # First one is mandatory section named "global". - # Run functional sections listed here and configured under the global. + +# Run functional sections listed here and configured under the global. + run dl ul - # If NAT/MASQUERADING is used then packets marking is recommended - # to manage the traffic uploaded from local network. Otherwise, if - # you utilize owned public IP addresses or use imq interfaces - # for upload shaping, then comment out or remove - # the mark-on-ifaces directive. - # On above assumptions, for uploaded packets marking, - # choose eth0 interface here. + +# If NAT (SNAT/NAPT/Masquerading) is used then packets marking is supported +# in order to allow NiceShaper distinguish the host's traffic uploaded from the LAN +# unless there are only public IP addresses in the LAN (without NAT) or IMQ +# interfaces are used for upload traffic shaping (IMQ interfaces +# as a workaround method for NAT problem is supported as well). +# Due to egress shaping rule, eth0 interface is right for uploaded packets marking. +# If not needed, comment out or remove the parameter below to reduce CPU usage. + mark-on-ifaces eth0 - # Define, space separated, list of local subnets to be controlled. + +# Define, space separated, list of routed local subnets. + local-subnets 192.168.0.0/24 - # It's worth to define, at least, LAN interface throughput. - # It's needed in class.conf to manage local traffic. + +# Auto-hosts directive expects the pairs of functional sections connected with +# the interfaces. This directive could appear to be quite complicated, +# but could be easier understand after looking into the class.conf file. +# Thanks to auto-hosts feature, it's easy to quickly configure traffic shaping +# using host directive within class.conf file, just by defining the list +# of local network hosts using their IP addresses and chosen names. +# Auto-hosts directive tells the functional sections which are expected +# to contain the classes, automatically created behind the host directive, +# and tells the interfaces onto which such classes have to be placed. +# +# Example below means that behind each of defined hosts, two classes are +# automatically created: +# First class - contained within dl section and placed onto the eth1 interface +# Second class - analogically, for the pair of "ul" and "eth0" values. + + auto-hosts dl eth1 ul eth0 + +# It could be needed to define the throughput of, at least, LAN interface. +# For example in order to allow the local traffic to be shaped at full speed. + iface-eth1 speed 1000Mb/s - # Some options for feature that allows getting status during work. - status unit kb/s file no -# After global section, create functional sections. +# After global section, there are needed the functional sections. # # Functional section reflects one certain direction of traffic. -# That's why each internet access uplink needs 2 functional sections. - -# Let's configure first functional section and name it short "dl". -# This section will handle download traffic (mode download). -# Functional section name is unrestricted and -# it hasn't got any parallel with section mode. +# That's why each internet access link needs 2 functional sections. +# +# Let's configure the first functional section and name it, shortly, e.g. "dl". +# This section will handle download traffic (due to mode download parameter).

    - # Set achievable broadband throughput. + +# Set the stable truly achievable broadband throughput in download direction. + section speed 20Mb/s - # Set expected traffic where 5%-10% of achievable are sacrificed. + +# Set expected traffic level, where 5%-10% of achievable has to be sacrificed. + section shape 19Mb/s - # Set section mode: - # download: designed to manage the incoming from the internet traffic. - # upload: for opposite direction traffic. + +# Set section mode, depending on the section role: +# Download - designed to handle the incoming from the internet traffic. +# Upload - for opposite direction traffic. + mode download - # Set how often reload(adjust) this section. - # Lower values give better reaction but increase CPU load. + +# Set how often adjust(reload) the classes contained within this section. +# Constant monitoring and adjusting the classes is the main point of +# dynamic traffic shaping feature. The lower value, the better reaction +# is obtained, but increased CPU load could be observed. +# In case of relatively slow Internet access, shared between a large +# number of hosts, adjusting should occurs as often as possible. + reload 2s - # At the end, set some defaults for classes included to this section. + +# At the end, set some defaults for classes contained within this section. +# Just use classes' parameters. + low 256kb/s ceil 5Mb/s strict 70 -# Configure second functional section. -# This section will handle upload traffic. +# Finally, configure the second functional section. +# Purpose is to handle the upload traffic.