Interesting... I don't have access to PPPoE, so I really can't test it. Sounds
reasonable, however.
One minor point - if you do a DIFF, diff old v. new not new v. old (why? Because old
v. new can be applied to the code)!
So, do the diff (diff -U3 old new) and send it to [EMAIL PROTECTED] for Luca to apply.
-----Burton
---------- Original Message ----------------------------------
From: Stefano Picerno <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Date: Mon, 15 Jul 2002 16:52:57 +0200 (CEST)
>Last version of ntop (ntop-current.tar.gz) does not handle correctly PPPoE
>data on linux (kernel 2.4.18) with libpcap-0.7.1.
>
>In fact, no data is handled by ntop when capturing from interface ppp0; I
>found that the ppp0 interface is using a datalink type set to
>DLT_LINUX_SLL. The captured packet follows a 16 byte header (found in
>sll.h in libpcap).
>Skipping it and calling processIpPkt with the rest of the packet made ntop
>work on ppp0 interface.
>
>Don't know if it's the correct way to operate, but with the following
>modification, I could make it work!
>
>diff ./pbuf.c /root/orig/ntop-current/ntop/pbuf.c
>1781,1788d1780
>< case DLT_LINUX_SLL:
>< #define SLL_HDR_LEN 16
>< length = h->len;
>< length -= SLL_HDR_LEN;
>< ether_src = ether_dst = NULL;
>< processIpPkt(p+ SLL_HDR_LEN , h, length, ether_src, ether_dst,
>actualDeviceId);
>< break;
><
>1817,1819c1809
>< && (myGlobals.device[deviceId].datalink != DLT_RAW)
>< && (myGlobals.device[deviceId].datalink != DLT_LINUX_SLL)
>< ) {
>---
>> && (myGlobals.device[deviceId].datalink != DLT_RAW)) {
>
>Bye
> Stefano
>
>_______________________________________________
>Ntop mailing list
>[EMAIL PROTECTED]
>http://lists.ntop.org/mailman/listinfo/ntop
>
__________________________________________________
D O T E A S Y - "Join the web hosting revolution!"
http://www.doteasy.com
_______________________________________________
Ntop mailing list
[EMAIL PROTECTED]
http://lists.ntop.org/mailman/listinfo/ntop
