[Ntop-dev] Running PPPoE or PPPoA? Please help!
Burton M. Strauss III
ntop-dev@unipi.it
Mon, 16 Sep 2002 16:38:20 -0500
We are trying to determine the header sizes for PPPoE and PPPoA connections
when ntop is monitoring them. If you are running ntop on a PPPoE or PPPoA
network, we need your help, if you have gdb installed and a few minutes...
If you're running ntop for mission critical stuff, don't bother, but for a
typical home user, this shouldn't cause any problems.
This won't fix any major problem -- just make the mtuSize reporting
correct...
What do I need you to do?
First, look at the ntop log lines to see what the thread # is for the PPPoE
or PPPoA interface:
Sep 16 12:33:10 tigger ntop[17801]: Started thread (6151) for network packet
sniffing on eth0.
Sep 16 12:33:10 tigger ntop[17801]: Started thread (7176) for network packet
sniffing on eth1.
$ su -
to become root
# ps -axf | grep ntop
(or whatever it is on your system) to see the running ntop processes
17801 ? S 0:00 /usr/bin/ntop -i eth0,eth1 -p
/usr/share/ntop/protocol.list -P /usr/share
17804 ? S 0:00 \_ /usr/bin/ntop -i eth0,eth1 -p
/usr/share/ntop/protocol.list -P /usr/s
17805 ? S 0:01 \_ /usr/bin/ntop -i eth0,eth1 -p
/usr/share/ntop/protocol.list -P /u
17807 ? S 0:00 \_ /usr/bin/ntop -i eth0,eth1 -p
/usr/share/ntop/protocol.list -P /u
17808 ? S 1:18 \_ /usr/bin/ntop -i eth0,eth1 -p
/usr/share/ntop/protocol.list -P /u
17809 ? S 0:00 \_ /usr/bin/ntop -i eth0,eth1 -p
/usr/share/ntop/protocol.list -P /u
17810 ? S 0:00 \_ /usr/bin/ntop -i eth0,eth1 -p
/usr/share/ntop/protocol.list -P /u
17811 ? S 0:09 \_ /usr/bin/ntop -i eth0,eth1 -p
/usr/share/ntop/protocol.list -P /u
17812 ? S 0:03 \_ /usr/bin/ntop -i eth0,eth1 -p
/usr/share/ntop/protocol.list -P /u
With the PID of the root ntop process, fire up gdb:
# gdb /usr/bin/ntop 17801
Once gdb finishes chuckling to itself:
(gdb) list pbuf.c:1600
You're looking for this line (IIRC it's 1598 in 2.1.2):
1604 h_save = h, p_save = p;
(gdb) info thread
9 Thread 7176 (LWP 17812) 0x4042fb0e in __select () at __select:-1
8 Thread 6151 (LWP 17811) 0x4042fb0e in __select () at __select:-1
7 Thread 5126 (LWP 17810) 0x4042fb0e in __select () at __select:-1
6 Thread 4101 (LWP 17809) 0x40376bb5 in __sigsuspend (set=0x4308097c)
at ../sysdeps/unix/sysv/linux/sigsuspend.c:45
5 Thread 3076 (LWP 17808) 0x404035b1 in __libc_nanosleep () at
__libc_nanosleep:-1
4 Thread 2051 (LWP 17807) 0x40376bb5 in __sigsuspend (set=0x4208067c)
at ../sysdeps/unix/sysv/linux/sigsuspend.c:45
3 Thread 1026 (LWP 17805) 0x404035b1 in __libc_nanosleep () at
__libc_nanosleep:-1
2 Thread 2049 (LWP 17804) 0x4042e3f7 in __poll (fds=0x80e3744, nfds=1,
timeout=2000)
at ../sysdeps/unix/sysv/linux/poll.c:63
1 Thread 1024 (LWP 17801) 0x40403567 in __libc_pause () at
__libc_pause:-1
to see the running threads and this gives you the mapping from pthreads #s
(6151) to the kernel...
Switch to the appropriate thread:
(gdb) thread 8
and set a breakpoint on the line above
(gdb) break pbuf.c:1604
(gdb) cont
When ntop breaks,
(gdb) print *h
$3 = {ts = {tv_sec = 1032210598, tv_usec = 432213}, caplen = 60, len = 60}
(gdb) print /x *p@60
$6 = {0x2, 0x0, 0x0, 0x0, 0x0, 0x5, 0x0, 0xa0, 0xcc, 0x28, 0x3b, 0xdc, 0x8,
0x0, 0x45, 0x0, 0x0,
0x28, 0xc5, 0xb, 0x40, 0x0, 0x80, 0x6, 0x60, 0x30, 0xc0, 0xa8, 0x2a, 0x23,
0xc0, 0xa8, 0x2a,
0x20, 0xf, 0x32, 0x0, 0x16, 0xad, 0xdb, 0x16, 0xd1, 0x76, 0x2a, 0x9, 0x3e,
0x50, 0x10, 0x7c,
0xb7, 0xa, 0x2c, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}
(gdb)
(48 or 60 bytes is more than enough)
What you're looking at is the LOW LEVEL (Ethernet) header (or, for PPPoE and
PPPoA, their headers, whatever they may be). Followed by the TCP/IP header:
(The Ethernet header is DestMAC, SrcMAC, Type)
02:00:00:00:00:05 00:00:CC:28:3B:DC 0x0800
(The IP header begins Version, HeaderLength, ServiceType, etc. ...
0x4 (IPv4)
0x5 (5 chunks of 4 octets or 20 bytes)
0x0000 - normal service
Then you can let ntop rip via this:
(gdb) clear pbuf.c:1604
Deleted breakpoint 1
(gdb) cont
Continuing.
Press Control-C:
Program received signal SIGINT, Interrupt.
[Switching to Thread 1024 (LWP 17801)]
0x40403567 in __libc_pause () at __libc_pause:-1
-1 __libc_pause: No such file or directory.
in __libc_pause
(gdb) quit
The program is running. Quit anyway (and detach it)? (y or n) y
Detaching from program: /usr/bin/ntop, process 17801
[root@tigger root]#
Thanks!
-----Burton
If you want to know more, keep reading...
Taviso is running PPPoA and has problems with the mtu classification. In
poking into the code, it's wrong in a couple of ways. Some of the value are
bogus. But it's also quite hard to track down the "right" ones. Note that
this doesn't affect much - just the mtu counts and the handling of some
stuff in nfsPlugin.c. Still, it should be cleaned up.
There is a table in globals-core.c that has these values. We don't control
assignment of the "magic" numbers, that's done in libpcap. So we're
reactive here.
I've committed the prep changes to the cvs. That is, the ones that set up
the table so it can be enlarged as necessary, and the values we know are
populated into it. There are also some info messages now during startup
about the DLT_, mtu and header values.
For most users it's ok right now. Even for users on odd-ball links, it
might even give you some classifications, as the default for unknown DLT_
values is mtu 1500, header 0. However, that's a case of failing safely --
do SOMETHING reasonable, even if it isn't right.
In the Linux world, 113 is the problem child - it's used (apparently) for
both PPPoE and PPPoA.
>From the comments at tcpdump.org:
/*
* 106 is reserved for Linux Classical IP over ATM; it's like DLT_RAW,
* except when it isn't. (I.e., sometimes it's just raw IP, and
* sometimes it isn't.) We currently handle it as DLT_LINUX_SLL,
* so that we don't have to worry about the link-layer header.)
*/
...
/*
* This is for Linux cooked sockets.
*/
#define DLT_LINUX_SLL 113
My concern is that we can't just assume 113 is PPPoA, as we know from others
that it's also PPPoE.
I have to believe that the whole point of PPPoA and PPPoE is to hide the
oE/oA stuff from the application, but ntop isn't an application. We're
reading at a pretty low level (Ethernet or other protocol, such as PPPoA,
frame):
pcap_open_live(myGlobals.device[i].name,
myGlobals.enablePacketDecoding == 0 ? 68 :
DEFAULT_SNAPLEN,
myGlobals.disablePromiscuousMode == 1 ? 0 : 1,
100 /* ms */, ebuf);
See, we're only grabbing the 1st 68 or 384 bytes of the packet.
Unfortunately, the code flowing from #define PACKET_DEBUG doesn't work
anymore... besides, that will get you burried in output.
We already have code for 113, and it's a bit of a hack... besides, based on
the RFC's I've read, it's wrong...
/* PPPoE patch courtesy of Stefano Picerno <stefanopp@libero.it> */
#ifdef _linux
case DLT_LINUX_SLL: /* Linux capture interface */
#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;
#endif
The RIGHT change is to figure out what's in those 14 or 16 or whatever bytes
and how to tell them apart. Hence why I'm asking for help...
References:
rfc2516 - Method for Transmitting PPP Over Ethernet (PPPoE)
rfc2364 - PPP Over AAL5
rfc1661 - The Point-to-Point Protocol (PPP)
-----Burton
-----Original Message-----
From: ntop-dev-admin@unipi.it [mailto:ntop-dev-admin@unipi.it]On Behalf
Of Burton M. Strauss III
Sent: Sunday, September 15, 2002 8:49 AM
To: ntop-dev@Unipi.IT
Cc: taviso@sdf.lonestar.org
Subject: RE: [Ntop-dev] ntop and PPPoA support
a) I'm working on it, keep your shorts in their normal position
b) Read the comments at tcpdump.org in the cvsweb for bpf.h
http://cvs.tcpdump.org/cgi-bin/cvsweb/libpcap/bpf/net/bpf.h?rev=1.61
(I'm only half being a smart-a**, I just found this as part of #a, above)
c) From the comment I'm preparing for the source change (#a):
/*
* Setup the mtu and header size tables.
*
* If mtuSize is wrong, the only problem will be 1)
erroneous-/mis-classification
* of packets as "too long", 2) the suspicious packet file, if
one, may have
* extra or missing entries, and 3) an erroneous line in the
report.
*
* If headerSize is wrong, the only problem will be in
nfsPlugin.c, but this may
* cause problems, as it uses the value to strip off the header so
it can analyze
* the nfs packet.
*
* These do need to be periodically resynced with tcpdump.org and
with user experience.
*
* History:
* 15Sep2002 - BStrauss
*
*/
-----Burton
<snip />