| Summary: | wondershaper / wshaper (new ebuild) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Christian Loitsch <gentoo-bug> |
| Component: | New packages | Assignee: | Default Assignee for New Packages <maintainer-wanted> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | enhancement | CC: | brebs, ecaddiga, flash3001, luke-jr+gentoobugs, per, trombik |
| Priority: | High | Keywords: | EBUILD |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
the ebulid
the wrapper skeleton a patch adding the mask-possibility Fixed wondershaper-1.1a.ebuild |
||
|
Description
Christian Loitsch
2003-05-10 10:23:50 UTC
Created attachment 11757 [details]
the ebulid
Created attachment 11758 [details]
the wrapper skeleton
Created attachment 11759 [details, diff]
a patch adding the mask-possibility
If a connection is restartet (for instance in Frace ADSL connections are cut every 24h), wondershaper does NOT restart itself. You need something like /etc/init.d/wondershaper restart in your /etc/ppp/ip-up If I find some time (highly unlikely the next 3 weeks), I will update the ebuild to propose such an config option. actually if you write the packetshaper rules correctly you dont need to restart it ... in other words, bind to your ppp0 interface rather than the actual IP you get i can't access my server right now, but I think I did bind it to ppp. And even if not, I have a static IP address. In any way wondershaper did not really work for me. It did make a difference, but for instance having multiple ftp connections at the same time and keeping the ping low was only possible when I halved my download speed :( (ADSL 512/128 over Alcatel Speedtouch Home) odd, i wonder if your rules were flushed or something ... i did build a set of packet shaping rules after reviewing wondershaper and the ADSL Bandwidth Limiting HOWTO ... it doesnt work as perfectly as you may want, but it really works about as well as should be expected considering the protocols/hardware/infrastructure/etc... that you're working with ... with dsl the best you can hope for is not having your upload severly affect your download. trying to control your download will just bring you headaches :) Doesn't wondershaper DEPEND on *anything*? Even if not, I believe it still needs a DEPEND="" line. it depends on sys-apps/iproute I forgot to add this line, sorry Tell you what. Fix up the ebuild get it all in order and I'll merge on your behalf. Not not.. Bouncing back to bug-wranglers perhaps another dev might want/need this functionality. Is this one going into portage? Or has it been rejected? Or are there any better alternatives? Just installed it on a box with a 2.6.7-gentoo-r11 kernel and iproute2 (2.4.7.20020116), and everything seems to run really smooth and nicely. The config isn't so very well-documented, however, so some commented configuration examples would be nice. Like this for example: # low priority source ports NOPRIOPORTSRC= #NOPRIOPORTSRC="80" # Web server traffic #NOPRIOPORTSRC="6881 6882 6883 6884" # BitTorrent traffic #NOPRIOPORTSRC="16384/C000" # Mldonkey ports 16384-32767 (The above are just examples to clarify the usage.) Created attachment 93276 [details]
Fixed wondershaper-1.1a.ebuild
Added iproute dependency and ~amd64 to the keywords.
I have used this on my amd64 for a little while now. I do not know how stable it is though thus ~amd64.
This might seem obvious to some but it was not to me so I will just say that the wrapper skeleton needs to be named rc.skel-1.1a, the patch needs to be named wondershaper-1.1a-gentoo.patch, and both need to be in the files subdirectory of where ever you put this in your portage overlay.
Last release in 2002. Sorry, but we are not adding this. |
