>As I'm busy researching the network behaviour of such peer-to-peer
>applications and I think there are two options to make ntop monitor such
>protocols:
>* Write a plug-in to handle the protocol. However AFAIK a plug-in cannot
>access the content of reassembled TCP transmissions, which is needed for
>analysis of most of these protocols.
>* Modify the ntop source. As the Napster example indicates this seems
rather
>difficult it one has no in depth knowledge of the ntop source code.
>More input on this is very welcome.
Um... I don't see any examples, but the structures (look at
pluginSkeleton.c) seem to show that you can indeed see the packet contents:
the comment in ntop.h is confusing (I'm pretty sure it, "/* Initialize here
all the plugin structs... */" applies to startFunc):
typedef struct pluginInfo {
/* Plugin Info */
char *pluginName; /* Short plugin name (e.g. icmpPlugin) */
char *pluginDescr; /* Long plugin description */
char *pluginVersion;
char *pluginAuthor;
char *pluginURLname; /* Set it to NULL if the plugin doesn't speak
HTTP */
char activeByDefault; /* Set it to 1 if this plugin is active by
default */
VoidFunc startFunc, termFunc;
PluginFunc pluginFunc; /* Initialize here all the plugin structs... */
PluginHTTPFunc httpFunct; /* Set it to NULL if the plugin doesn't speak
HTTP */
HashResizePluginFunc resizeFunct; /* Function called when the main hash is
resized */
char* bpfFilter; /* BPF filter for selecting packets that
will be routed to the plugin */
} PluginInfo;
I do think the skeleton is WRONG
static PluginInfo pluginInfo[] = {
{ "put here the plugin name as it will appere",
"describe what this plugin does",
"1.0", /* plugin version */
"Put here the author name",
"shortPluginName", /* http://<host>:<port>/plugins/shortPluginName */
1, /* Active Plugin */
termFunction, /* TermFunc */
handlePacket, /* PluginFunc */
handlePluginHTTPrequest,
"<BPF filter>" /* BPF filter */
}
};
should be:
static PluginInfo pluginInfo[] = {
{ "put here the plugin name as it will appere",
"describe what this plugin does",
"1.0", /* plugin version */
"Put here the author name",
"shortPluginName", /* http://<host>:<port>/plugins/shortPluginName */
1, /* Active Plugin */
startFunction, /* StartFunc */
termFunction, /* TermFunc */
handlePacket, /* PluginFunc */
handlePluginHTTPrequest,
resizeFunction, /* Hash ResizeFunc */
"<BPF filter>" /* BPF filter */
}
};
Which matches icmpPlugin.c:
static PluginInfo icmpPluginInfo[] = {
{ "icmpWatchPlugin",
"This plugin handles ICMP packets",
"1.0", /* version */
"<A HREF=http://luca.ntop.org/>L.Deri</A>",
"icmpWatch", /* http://<host>:<port>/plugins/icmpWatch */
1, /* Active */
NULL, /* no special startup after init */
termIcmpFunct, /* TermFunc */
NULL, /* PluginFunc */
handleIcmpWatchHTTPrequest,
NULL,
NULL /* no capture */
}
};
However, it sure looks like the handlePacket function has access to the
packet. From pbuf.c (debug lines snipped):
static void flowsProcess(const struct pcap_pkthdr *h, const u_char *p) {
FlowFilterList *list = flowsList;
while(list != NULL) {
if((list->pluginStatus.activePlugin)
&& (list->fcode[deviceId].bf_insns != NULL)
&& (bpf_filter(list->fcode[deviceId].bf_insns,
(u_char*)p, h->len, h->caplen))) {
list->bytes += h->len;
list->packets++;
if(list->pluginStatus.pluginPtr != NULL) {
void(*pluginFunc)(const struct pcap_pkthdr *h, const u_char *p);
pluginFunc = (void(*)(const struct pcap_pkthdr*,
const
u_char*))list->pluginStatus.pluginPtr->pluginFunc;
>>>>> pluginFunc(h, p);
}
} else {
}
list = list->next;
}
}
At which point you could do the analysis and tracking to your hearts
content. I'm guessing that the Napster stuff 1) became irrelevant 2)
doesn't work very well and 3) was done in-line so you wouldn't have to go to
a plugins menu to get it... But that's all only a guess...
-----Burton
_______________________________________________
Ntop mailing list
[EMAIL PROTECTED]
http://listmanager.unipi.it/mailman/listinfo/ntop
