Új hozzászólás Aktív témák

  • chros

    őstag

    Szoval: [link]
    Elsodlegesen quota support-tal nem kell foglalkozni.
    Az upload korlatozas tul egyszerunek tunik.
    Es a download-ot sem ertem nagyon :)

  • bambano

    titán

    LOGOUT blog

    válasz chros #1 üzenetére

    az upload korlátozás azért egyszerű, mert nem lehet rendesen korlátozni, csak tranzitíven. ezt az is alátámasztja, hogy az elsőként linkelt lapon sem a bemenő interfészen korlátoznak, hanem a kimenőn.

    a download korlátozás működik rendesen.

    Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

  • Headless

    őstag

    válasz chros #1 üzenetére

    Hát én úgy gondolom az alapokhoz kéne visszamennünk... vagyis a tc-hez, amit az összes ilyen script használ...

    [link]

    Én próbáltam régebben összerakni, hfsc, és ingress schedulerekkel a qos scripts alapján, de nem jutottam sokra, ezért inkább azzzal a schedulerrel kéne megpróbálni, ami direkt a fix korlátozásra van, vagyis a "Token Bucket Filter"-el viszont ez nincs benne a "kmod-sched-core"-ban. hanem a sima "kmod-sched"-et kéne felrakni.

    Ha a korlátozás rész megvan utána már csak a filtert kell kitalálni, amihez openwrt oldalon is van segítség... És ha már felépítettük a rendszert, akkor már csak egy lépés egy közérthető webes felületet csinálni hozzá...

    LEDE - R3G/DIR860l -> https://tinyurl.hu/Ntkb/

  • chros

    őstag

    válasz bambano #2 üzenetére

    "az upload korlátozás azért egyszerű, mert nem lehet rendesen korlátozni, csak tranzitíven. ezt az is alátámasztja, hogy az elsőként linkelt lapon sem a bemenő interfészen korlátoznak, hanem a kimenőn."
    Bocs, de ezt egyaltalan nem ertem. :)
    Ezt nem a kimenon kene? (a peldaban eth1 a kimeno interface)

    "a download korlátozás működik rendesen."
    Hogyan, ebben a peldaban?
    simple.qos -t hasznalva: "The 3 band up and down separation is mostly on IP header attributes for QOS (DSCP field), which may or may not be used in client software. It does less with protocol/port."
    Ha jol ertem, akkor hasnlo dolgot kell csinalni az ingress-ben az alap 3-tier classification-nal: kiboviteni 4-re:
    +BL_RATE=`expr $CEIL / 2` # let's half the connection bandwidth
    +$TC class add dev $IFACE parent 1:1 classid 1:14 htb $LQ rate ${BL_RATE}kbit prio 4 `get_htb_adsll_string`
    +$TC qdisc add dev $IFACE parent 1:14 handle 140: $QDISC `get_limit ${ELIMIT}` `get_target "${ETARGET}" ${DOWNLINK}` `get_ecn ${EECN}` `get_quantum 300` `get_flows ${BL_RATE}` ${EQDISC_OPTS}

    Es a police filter-t nem latom, hova kene beilleszteni, itt mashogy epitkezik, mint az egress eseteben.
    Es az iptables sor hogyan nezne ki ebben az esetben?

    "Én próbáltam régebben összerakni, hfsc, és ingress schedulerekkel a qos scripts alapján,"
    En viszont szivesebben latnam az sqm scriptek egyeket (vagy akar 2-t vagy mindet :) ) modositva, s ezzel elvezve minden elonyet: [link] . Mar csak azert is, mert ezeket mar megirtak a hozzaertok, s csak "kicsit" kell rajta valtoztatni (lasd lentebb).

    Mint a fenti linkekebol kiderul, a kulonbozo queue scriptek egyaltalan nem azonos alapokra epitkeznek, s masra vannak kitalalva. Pl. [link]
    Az alapotletben simple.qos -t hasznalnak, de hosszu tavon nekem a hfsc_lite.qos tetszene (ez hasonlit leginkabb az eddig hasznalt sima QoS-re OpenWRT-bol).

    Eloszor simple.qos-t kene kitalalni, probakeppen (ez tunik egyszerubbnek). Lasd fentebb.

    I. Eric otlete lepesekre bontva:
    1. "Lets assume we only want to control access to the WAN for a host, and leave local communication alone."
    2. "Generically (cake or no), there could be a way to assign a subclass shaper with its own qdisc"
    3. "and filter on IP (tc filter ~ u32 match src / dst) or MAC through contrack.
    4. "A generic functions.sh subroutine would need to have the shaper as a parameter and know how to handle each shaper. The qdisc is already a dynamic option. As long as all scripts followed class numbering convention, this could be a plugin for all of them from functions.sh."
    5. "It gets ugly fast though. CPU load for each class ingress and egress."
    6. "IPV4 address white/black list from DHCP is easy. But IPV6 has so many permutations."
    7. "So you can only have a single router so that contrack can hold the mac addresses."

    Nezzuk, ami jonak tunik:
    - 1. , 7.
    - 6. : IPV6-tal nem kell belulrol foglalkoznunk, de ez mar csak kozmetika a vegen
    - 5. : ez sem tunik nagy gondnak, altalaban 1-2 szabalyra lenne szukseg (nekem pl. 1 ingress es 1 egress boven eleg: az mas kerdes, hogy lehet, hogy ez nem csak 2, hanem akar 6 is az adott queue scriptben implementalva; nem tudom)

    Es ami macera:
    - 2. : ezt kene jol kitalalni minden queue scriptre (vagy parra) , es ez a legnagyobb problema
    - 3. : ezt konnyu scriptelni szamunkra kesobb akar a ti webes feluleteteken
    - 4. : erre nincs szuksegunk, most ugy gondolom (legalabb is az elejen)

    Igy, ha jol ertem, "csak" a 2. pont a kerdes, de az erosen. :)

    Ha egyetertetek ezzel, akkor csinalok egy git repot ehhez, s megkezdothet a kiserletezes. (Es abban is biztos vagyok, ha mar van feleksz/kesz kod, akkor a guruk is reneznek majd az sqm-sripts projectbol, s segitenek benne.)

    [ Szerkesztve ]

Új hozzászólás Aktív témák