On 2/8/06, Ulf Lamping <ulf.lamping@xxxxxx> wrote:
>
> > > I had a strange problem with an error when linking the libs with the lua plugin, but the error vanished somehow. I hope the makefiles work for others, too.
> > >
> > > BTW, Luis I noticed that your "Hello World" demo doesn't print anything anywhere, even not into the debug window, when using it with ethereal. tethereal works fine with lua. Is this windows specific or is the print function not supported in ethereal?
> >
> > I think writing to stdout does not work with eteheral on windows, the
> > more, just yesterday while working on main.c I've skim-read some
> > comment that hinted me that writing to stdout might cause problems to
> > the capture child on windows.
> >
> > Ulf, can you confirm that?
>
> I don't know the exact "lua way", I'll explain the "C way".
>
[...]
> Of course, if the printf is done before the Preferences are read in, you still won't see anything. I don't know at which time the lua script is processed.
>
> While using tethereal, theres obviously a console available, so the problem doesn't appear.
>
> The current code uses the same main function for both Ethereal as the main application and as a capture child task. The communication between the main and the child task is done using a pipe which in turn uses stdout.
>
> You shouldn't put anything to stdout in the main function until capture_loop_start() is called (main.c lines 1857-2638, including all subfunctions called)!
the "body" of the script will be executed under
main()
epan_init() main.c:2116
final_registration_all_protocols() epan.c:70
register_lua() packet-lua.c:351
lua_load_script() packet-lua.c:235
so it is in the "hot-area".
> This will change if I'll find the time to change it, so we use dumpcap instead of Ethereal for the capturing task.
>
> >
> > In that case I I'll have override lua's "print" and write our own that
> > uses g_log instead of printf and make sure that stdout is not directly
> > accessible from Lua when running ethereal (at least on Windows).
> >
>
> For the reasons above this sounds like a good idea.
taken into account what you've told we need to do something more:
- we need to buffer all user prints in the hot-area (while debugging
people will need to print! we can tell them to use tethereal but, what
if they are debugging gui stuff?)
- then flush them to the console after or when create_console() was
called [main.c:2193].
I see two options:
a) That could be made for all ethereal, registering a log hanlder that
buffers at the very beggining and flushing its buffer in
create_console() while switching to console_log_handler() on windows
or
b) I could do the same with "print" just for lua using two different C
functions one that buffers and then switch to one that logs, whenI
swicth I could flush.
for a) I could write the code but someone else should do the testing.
as far as b) goes I can do it and test it myself the problem is that
the switching won't be invokable until init_dissection() which migh
not even be called if the user closes ethereal before opening a
capture file or starts capturing.
Any other Ideas?
Luis.
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
