[ previous ] [ next ] [ threads ]
 
 From:  "Konstantin Rudoy" <subscribe at k dot rudoy dot com>
 To:  <m0n0wall at lists dot m0n0 dot ch>
 Subject:  Re: [m0n0wall] The traffic grapher - A problem and a question/comment
 Date:  Thu, 1 Apr 2004 15:26:48 -0500
Just go to Adobe site and install latest SVG viewer.

I had the same problem but it fixed by that

Thank you,
Konstantin

----- Original Message ----- 
From: "Adam Nellemann" <adam at nellemann dot nu>
To: <m0n0wall at lists dot m0n0 dot ch>
Sent: Thursday, April 01, 2004 1:38 PM
Subject: [m0n0wall] The traffic grapher - A problem and a question/comment


> Hi,
>
> Thanks for the Beta Manuel, always nice to get new versions,
> especially when there are interessting new features to play around with :)
>
> I was looking very much forward to try the new Traffic grapher, but
> unfortunatly it doesn't work for me :(
>
> When I open the page, the plugin will show an empty graph, but then it
> pops up an error in IE, saying "Object expected", with a title of
> "Microsoft JScript runtime error". Pressing "OK" (only choice) removes
> the popup, but the graph, while visible, has no data plots. The same
> error is shown again if the interface is changed or the page is
> refreshed. Sometimes IE will even crash (I think this happens if I
> refresh before OK'ing the popup, not sure though?)
>
> However since nobody else have reported similar problems, I must
> assume this has to do with my particular IE installation (which is
> sick in other ways too, so...) Unless someone else have experienced
> this and/or know how to solve the issue, I guess I'll have to wait for
> my upcomming hardware upgrade and the following reinstallation of Win2k.
>
> = = =
>
> So much for my problem. My question/comment is this:
>
> I was a bit surprised to see this particular (SVG) solution used for
> the traffic grapher. Perhaps someone would care to elaborate on the
> reasons behind this choice?
>
> Taking a stab at an answer myself: Am I correct in assuming that the
> use of SVG allow you to implement the m0n0wall side of the graph
> purely in PHP, with a minimum of processing taking place on the
> m0n0wall box, and without the need for any additional binaries?
>
> Even if I can see the benefits from this (that is, if my guess was
> correct), there is a lot to be said for a solution that does not
> involve a particular plugin being installed on the client browser (as
> the posts about non-IE browser problems shows).
>
> I understand that time and effort has already been put into this, and
> so it might be a bit late to suggest another approach, and I haste to
> add that I'm sure I, and most other users, will be perfectly happy
> with the current solution. So please don't take the suggestion below
> for anything other than it is. I wouldn't presume to know better than
> Manuel or anyone else working on the m0n0wall project. I'm far to
> impressed with the product as a whole for that :)
>
> Personally though, I would consider an approach where a dynamically
> produced image (PNG or GIF) was used to show the graph(s), so as to
> avoid the need for a plugin and thus keeping the webGUI as compatible
> as possible. I'm rather sure there are a number of utilities
> available, that will produce such graph-images on the fly, given the
> right data (indeed this was the only way to do graphs, counters and
> other dynamic images, back when cgi-scripts were the only kind of HTML
> "plugin" available).
>
> While I'm rather sure most such graph-producing programs would pose no
> security risk, nor impact the stability of m0n0wall, I do realise that
> they might use some resources, which could be a minor problem for some
> Soekriss users. But I get the impression that this new graph page
> wasn't intended for doing long-term statistical analysis, and so
> wouldn't be expected to remain active for extended periods (also the
> thread/process could be given a very low priority, ensuring anything
> performance related will be getting what it needs). That being said,
> I'm sure most such programs will be quite modest in their requirements
> (after all they were made to run on webservers, often serving
> individual images to a large number of concurrent users).
>
> In case this approach is deemed unfeasible, I'd consider a solution
> similar to the current one, but using Shockwave Flash instead. At
> least this is a very common, and widely supported plugin. Some
> browsers (notably IE) even come with built-in Flash support, removing
> the need to install a plugin altogether. This way, users won't have to
> install a plugin they might not use for anything other than the
> m0n0wall graph (something you could argue could pose an entirely
> different kind of security and bug risk, albeit on the client box
> instead of m0n0wall).
>
> There is also the issue of company policies regarding installation of
> plugins to consider, which will probably be less of an issue with
> Flash, and non-existent with the dynamic-PNG solution.
>
> Finally, I'd like to comment on those posts suggesting that one use
> MRTG, Cacti, or whatever SNMP graphers are out there for any
> graphing-needs not catered to by the new m0n0wall graphs: While this
> does provide some very nice graphs and other features, there are a
> number of reasons why this isn't very optimal, or even feasible, for
> many m0n0wall users: First of all most of these work by servering HTML
> pages, and will thus require you to install and run a webserver,
> somewhat overkill if you otherwise have no use for this on your LAN.
> In addition they typically aren't exactly plug-n-play, making it a
> problem for some users to get it properly configured or even running
> at all, not to mention making sure the webserver isn't otherwise
> posing a security risk.
>
> I have been able to find a few stand-alone SNMP clients, but none of
> these were any good. Thus I should think there will be a lot of users
> who would be very happy to be able to satisfy their "graphing needs"
> through whatever is provided in the m0n0wall webGUI, at least until
> someone decides to make a nice, small SNMP client with the necessary
> graphing features.
>
> BTW: I'd be happy to produce such a util, only I would need some help
> with the SNMP part, and also: I'd find it more worthwhile, if there
> was a bit more information provided through SNMP from m0n0wall, making
> it possible to show a tad more than just in/out traffic for each
> interface (such as traffic per-host, -protocol,
> -shaper_rule/queue/pipe, and/or -firewall rule).
>
> Just in case somebody is already working on (or considering) such a
> program: I've got some quite nice OpenGL graph code, which I'd be
> happy to share! I'm sure I could easily port it to a more compatible
> ANSI C++ version, if needed (currently a bit C++ Builder specific),
> and I'd of course be happy to help with the development if needed/wanted.
>
> Anyway, just my two cents. And don't get me wrong: No matter how it is
> implemented, I'm a sucker for anything graphic and "blinkenlichten"
> and am very happy to see this particular feature making it into the
> beta (and hopefully the release at some point). Now, about that
> suggestion for a 3D screensaver in the m0n0wall webGUI... :))
>
>
> Regards,
>
> Adam.
>
>
> P.S. Please excuse my longwindedness, can't help it I'm afraid :(
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
>
>
>