[ previous ] [ next ] [ threads ]
 From:  Falcor <falcor at netassassin dot com>
 To:  Adam Nellemann <adam at nellemann dot nu>
 Cc:  m0n0wall dash dev at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall-dev] Traffic Shaper and other things
 Date:  Wed, 09 Jun 2004 10:05:18 -0500
concur.  I would love to see MAC filtering.  But alas, my php skilz are 
not so "good"

Adam Nellemann wrote:

> Quark IT - Hilton Travis wrote:
>> Hi,
>> I'm just reading through documentation on the FreeBSD dummynet that 
>> m0n0wall
>> uses for its traffic shaper so I can get a better understanding of 
>> its use
>> (in general, and in m0n0wall in particular) and I have a few 
>> questions, some
>> of which have been asked before in the users list, and some of which 
>> I can't
>> find in my email archive here.
>> 1. I have 4 pipes and 4 queues (one disabled) defined in the m0n0wall
>> Traffic Shaper in my test setup.  The configuration, although silly (in
>> hindsight) works as intended and before I change it to something a 
>> lot more
>> sensible, I decided to have a look at the ipfw output from the 
>> settings as
>> they stand:
>>     $ ipfw list
>>     50000 allow ip from to any
>>     50001 allow ip from any to
>>     50002 queue 2 ip from to any out via ng0
>>     50003 queue 3 ip from any to out via sis0
>>     50004 queue 4 ip from to any out via ng0
>>     65535 allow ip from any to any
>>    Now, with my current Traffic Shaper settings, this all corresponds,
>> except for the fact that there are none of my Pipes shown in the ipfw
>> listing, nor are any queues referring the Pipes.
>>    Can anyone explain these things?  Do Pipes *only* show up in the 
>> "ipfw
>> pipes show" command?
>> 2. Will there be an "Advanced" or similar option for the "mask" 
>> employed in
>> the future?  The dummynet "mask" is a very powerful part of the whole
>> traffic shaping functionality, and this has been seriously limited in 
>> the
>> m0n0wall interface.  I really like the "source" and "destination" 
>> settings -
>> they make it easy for applying simple masking - but they also limit the
>> masking functionality for those who'd like to make more use of the power
>> this feature offers.  This could be achieved by adding another entry 
>> to the
>> "mask" dropdown, allowing "advanced" and having the user choose 
>> checkboxes
>> for the "mask" properties (i.e. proto, src-ip, dst-ip, src-port, 
>> dst-port),
>> and then enter the required values in text fields next to these 
>> checkboxes.
>> One idea, anyway
>> 3. The order of the tabs seems illogical to me.  Rules generally 
>> apply to
>> queues that generally feed into pipes.  The current tab order of Rules,
>> Pipes, Queues doesn't follow this logic - I think that last two tabs 
>> need to
>> be switched.
>> 4. Would there be any interest in a 4th tab - Advanced - where the
>> administrator can configure the more advanced functionality of dummynet?
>> There are a number of parameters that can be altered to tune dummynet
>> performance on your machine, such as sysctl net.inet.ip.fw.one_pass, 
>> but the
>> general user will probably be happy to leave these at their default 
>> values.
>> I'm sure that users of Soekris boxes and other systems with limited
>> resources would welcome these advanced additions.  I'd sure like to 
>> be able
>> to process traffic not only by IP, but also by protocol after it is 
>> shaped
>> by IP.  Would be really nice, that!
>> 5. The ability to set the queue size on individual Pipes would be rather
>> handy for those people on slowish links.  As the default is ideal for
>> Ethernet connections, and as few of us have a 10 mbps or faster link 
>> to the
>> Internet, being able to manually change the queue size on all created 
>> Pipes
>> would be a rather nice feature.  This would be especially useful for 
>> those
>> of us on slower ADSL links such as 512/128 kbps or 256/64 kbps.
>> 6. Adding the "plr" field would be a great feature - it would enable all
>> users worldwide to feel like they are on the Telstra broadband 
>> network.  A
>> similar effect could be achieved by randomly blocking all outbound 
>> traffic
>> to any:25/TCP and any:110/TCP.  :)
>> 7. Scheduled rules.  For home users in particular, it would be really 
>> nice
>> to be able to have rules automatically enabled/disabled according to 
>> a given
>> schedule - for example, the SOHO PCs get more highly weighted during
>> business hours, and the home/game machines get more heavily weighted 
>> after
>> hours.  This could be used for general firewall rules as well, not just
>> traffic shaping rules.
>> 8. Aliases - is there any chance that these can be shown in a dropdown?
>> This would make it significantly easier, as the aliases are case 
>> sensitive,
>> and sometimes with a long list of aliases it can be hard to remember 
>> all the
>> aliases in the list.  Of course, being able to also type into this 
>> box would
>> be essential.
>> 9. Aliases revisited.  It would also be really nice to be able to 
>> configure
>> port ranges as an alias to enhance the list that m0n0wall provides by
>> default (ftp, ssh, telnet, smtp, dns, http, pop3, imap, https).  This 
>> could
>> be done in a second tab, and would allow people to configure their own
>> aliases such as rdp (3189), 2k3rdp (4125), vnc (5900), pcanyone 
>> (5631-5632),
>> and so on.
>> 10. MAC filtering is possible in ipfw, but not implemented in m0n0wall.
>> This could also be as option that many users could find useful - 
>> especially
>> those who wish to shape a particular user that they don't have much 
>> other
>> control over, such as students and so on.
>> 11. Enable/Disable - in the Traffic Shaper,  Firewall and maybe even NAT
>> sections, it would be *really* nice to have the enable/disable 
>> checkbox on
>> the list, not on the individual "edit" pages.  This would allow much 
>> easier
>> editing of these rules, and would quite probably make life much 
>> easier for
>> the "scheduled rules" people, especially if someone's writing code to 
>> make
>> mass changes.
> Just wanted to add my vote for all the above. with the possible 
> exception of 6. and 11. since the latter has already been implemented 
> in the beta, and the former seem to be mainly a joke ;)
> Adam.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: m0n0wall dash dev dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash dev dash help at lists dot m0n0 dot ch