/usr/share/ntop/html/faq.html is in ntop-data 3:5.0.1+dfsg1-2.2ubuntu1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602 1603 1604 1605 1606 1607 1608 1609 1610 1611 1612 1613 1614 1615 1616 1617 1618 1619 1620 1621 1622 1623 1624 1625 1626 1627 1628 1629 1630 1631 1632 1633 1634 1635 1636 1637 1638 1639 1640 1641 1642 1643 1644 1645 1646 1647 1648 1649 1650 1651 1652 1653 1654 1655 1656 1657 1658 1659 1660 1661 1662 1663 1664 1665 1666 1667 1668 1669 1670 1671 1672 1673 1674 1675 1676 1677 1678 1679 1680 1681 1682 1683 1684 1685 1686 1687 1688 1689 1690 1691 1692 1693 1694 1695 1696 1697 1698 1699 1700 1701 1702 1703 1704 1705 1706 1707 1708 1709 1710 1711 1712 1713 1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1746 1747 1748 1749 1750 1751 1752 1753 1754 1755 1756 1757 1758 1759 1760 1761 1762 1763 1764 1765 1766 1767 1768 1769 1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1789 1790 1791 1792 1793 1794 1795 1796 1797 1798 1799 1800 1801 1802 1803 1804 1805 1806 1807 1808 1809 1810 1811 1812 1813 1814 1815 1816 1817 1818 1819 1820 1821 1822 1823 1824 1825 1826 1827 1828 1829 1830 1831 1832 1833 1834 1835 1836 1837 1838 1839 1840 1841 1842 1843 1844 1845 1846 1847 1848 1849 1850 1851 1852 1853 1854 1855 1856 1857 1858 1859 1860 1861 1862 1863 1864 1865 1866 1867 1868 1869 1870 1871 1872 1873 1874 1875 1876 1877 1878 1879 1880 1881 1882 1883 1884 1885 1886 1887 1888 1889 1890 1891 1892 1893 1894 1895 1896 1897 1898 1899 1900 1901 1902 1903 1904 1905 1906 1907 1908 1909 1910 1911 1912 1913 1914 1915 1916 1917 1918 1919 1920 1921 1922 1923 1924 1925 1926 1927 1928 1929 1930 1931 1932 1933 1934 1935 1936 1937 1938 1939 1940 1941 1942 1943 1944 1945 1946 1947 1948 1949 1950 1951 1952 1953 1954 1955 1956 1957 1958 1959 1960 1961 1962 1963 1964 1965 1966 1967 1968 1969 1970 1971 1972 1973 1974 1975 1976 1977 1978 1979 1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 2031 2032 2033 2034 2035 2036 2037 2038 2039 2040 2041 2042 2043 2044 2045 2046 2047 2048 2049 2050 2051 2052 2053 2054 2055 2056 2057 2058 2059 2060 2061 2062 2063 2064 2065 2066 2067 2068 2069 2070 2071 2072 2073 2074 2075 2076 2077 2078 2079 2080 2081 2082 2083 2084 2085 2086 2087 2088 2089 2090 2091 2092 2093 2094 2095 2096 2097 2098 2099 2100 2101 2102 2103 2104 2105 2106 2107 2108 2109 2110 2111 2112 2113 2114 2115 2116 2117 2118 2119 2120 2121 2122 2123 2124 2125 2126 2127 2128 2129 2130 2131 2132 2133 2134 2135 2136 2137 2138 2139 2140 2141 2142 2143 2144 2145 2146 2147 2148 2149 2150 2151 2152 2153 2154 2155 2156 2157 2158 2159 2160 2161 2162 2163 2164 2165 2166 2167 2168 2169 2170 2171 2172 2173 2174 2175 2176 2177 2178 2179 2180 2181 2182 2183 2184 2185 2186 2187 2188 2189 2190 2191 2192 2193 2194 2195 2196 2197 2198 2199 2200 2201 2202 2203 2204 2205 2206 2207 2208 2209 2210 2211 2212 2213 2214 2215 2216 2217 2218 2219 2220 2221 2222 2223 2224 2225 2226 2227 2228 2229 2230 2231 2232 2233 2234 2235 2236 2237 2238 2239 2240 2241 2242 2243 2244 2245 2246 2247 2248 2249 2250 2251 2252 2253 2254 2255 2256 2257 2258 2259 2260 2261 2262 2263 2264 2265 2266 2267 2268 2269 2270 2271 2272 2273 2274 2275 2276 2277 2278 2279 2280 2281 2282 2283 2284 2285 2286 2287 2288 2289 2290 2291 2292 2293 2294 2295 2296 2297 2298 2299 2300 2301 2302 2303 2304 2305 2306 2307 2308 2309 2310 2311 2312 2313 2314 2315 2316 2317 2318 2319 2320 2321 2322 2323 2324 2325 2326 2327 2328 2329 2330 2331 2332 2333 2334 2335 2336 2337 2338 2339 2340 2341 2342 2343 2344 2345 2346 2347 2348 2349 2350 2351 2352 2353 2354 2355 2356 2357 2358 2359 2360 2361 2362 2363 2364 2365 2366 2367 2368 2369 2370 2371 2372 2373 2374 2375 2376 2377 2378 2379 2380 2381 2382 2383 2384 2385 2386 2387 2388 2389 2390 2391 2392 2393 2394 2395 2396 2397 2398 2399 2400 2401 2402 2403 2404 2405 2406 2407 2408 2409 2410 2411 2412 2413 2414 2415 2416 2417 2418 2419 2420 2421 2422 2423 2424 2425 2426 2427 2428 2429 2430 2431 2432 2433 2434 2435 2436 2437 2438 2439 2440 2441 2442 2443 2444 2445 2446 2447 2448 2449 2450 2451 2452 2453 2454 2455 2456 2457 2458 2459 2460 2461 2462 2463 2464 2465 2466 2467 2468 2469 2470 2471 2472 2473 2474 2475 2476 2477 2478 2479 2480 2481 2482 2483 2484 2485 2486 2487 2488 2489 2490 2491 2492 2493 2494 2495 2496 2497 2498 2499 2500 2501 2502 2503 2504 2505 2506 2507 2508 2509 2510 2511 2512 2513 2514 2515 2516 2517 2518 2519 2520 2521 2522 2523 2524 2525 2526 2527 2528 2529 2530 2531 2532 2533 2534 2535 2536 2537 2538 2539 2540 2541 2542 2543 2544 2545 2546 2547 2548 2549 2550 2551 2552 2553 2554 2555 2556 2557 2558 2559 2560 2561 2562 2563 2564 2565 2566 2567 2568 2569 2570 2571 2572 2573 2574 2575 2576 2577 2578 2579 2580 2581 2582 2583 2584 2585 2586 2587 2588 2589 2590 2591 2592 2593 2594 2595 2596 2597 2598 2599 2600 2601 2602 2603 2604 2605 2606 2607 2608 2609 2610 2611 2612 2613 2614 2615 2616 2617 2618 2619 2620 2621 2622 2623 2624 2625 2626 2627 2628 2629 2630 2631 2632 2633 2634 2635 2636 2637 2638 2639 2640 2641 2642 2643 2644 2645 2646 2647 2648 2649 2650 2651 2652 2653 2654 2655 2656 2657 2658 2659 2660 2661 2662 2663 2664 2665 2666 2667 2668 2669 2670 2671 2672 2673 2674 2675 2676 2677 2678 2679 2680 2681 2682 2683 2684 2685 2686 2687 2688 2689 2690 2691 2692 2693 2694 2695 2696 2697 2698 2699 2700 2701 2702 2703 2704 2705 2706 2707 2708 2709 2710 2711 2712 2713 2714 2715 2716 2717 2718 2719 2720 2721 2722 2723 2724 2725 2726 2727 2728 2729 2730 2731 2732 2733 2734 2735 2736 2737 2738 2739 2740 2741 2742 2743 2744 2745 2746 2747 2748 2749 2750 2751 2752 2753 2754 2755 2756 2757 2758 2759 2760 2761 2762 2763 2764 2765 2766 2767 2768 2769 2770 2771 2772 2773 2774 2775 2776 2777 2778 2779 2780 2781 2782 2783 2784 2785 2786 2787 2788 2789 2790 2791 2792 2793 2794 2795 2796 2797 2798 2799 2800 2801 2802 2803 2804 2805 2806 2807 2808 2809 2810 2811 2812 2813 2814 2815 2816 2817 2818 2819 2820 2821 2822 2823 2824 2825 2826 2827 2828 2829 2830 2831 2832 2833 2834 2835 2836 2837 2838 2839 2840 2841 2842 2843 2844 2845 2846 2847 2848 2849 2850 2851 2852 2853 2854 2855 2856 2857 2858 2859 2860 2861 2862 2863 2864 2865 2866 2867 2868 2869 2870 2871 2872 2873 2874 2875 2876 2877 2878 2879 2880 2881 2882 2883 2884 2885 2886 2887 2888 2889 2890 2891 2892 2893 2894 2895 2896 2897 2898 2899 2900 2901 2902 2903 2904 2905 2906 2907 2908 2909 2910 2911 2912 2913 2914 2915 2916 2917 2918 2919 2920 2921 2922 2923 2924 2925 2926 2927 2928 2929 2930 2931 2932 2933 2934 2935 2936 2937 2938 2939 2940 2941 2942 2943 2944 2945 2946 2947 2948 2949 2950 2951 2952 2953 2954 2955 2956 2957 2958 2959 2960 2961 2962 2963 2964 2965 2966 2967 2968 2969 2970 2971 2972 2973 2974 2975 2976 2977 2978 2979 2980 2981 2982 2983 2984 2985 2986 2987 2988 2989 2990 2991 2992 2993 2994 2995 2996 2997 2998 2999 3000 3001 3002 3003 3004 3005 3006 3007 3008 3009 3010 3011 3012 3013 3014 3015 3016 3017 3018 3019 3020 3021 3022 3023 3024 3025 3026 3027 3028 3029 3030 3031 3032 3033 3034 3035 3036 3037 3038 3039 3040 3041 3042 3043 3044 3045 3046 3047 3048 3049 3050 3051 3052 3053 3054 3055 3056 3057 3058 3059 3060 3061 3062 3063 3064 3065 3066 3067 3068 3069 3070 3071 3072 3073 3074 3075 3076 3077 3078 3079 3080 3081 3082 3083 3084 3085 3086 3087 3088 3089 3090 3091 3092 3093 3094 3095 3096 3097 3098 3099 3100 3101 3102 3103 3104 3105 3106 3107 3108 3109 3110 3111 3112 3113 3114 3115 3116 3117 3118 3119 3120 3121 3122 3123 3124 3125 3126 3127 3128 3129 3130 3131 3132 3133 3134 3135 3136 3137 3138 3139 3140 3141 3142 3143 3144 3145 3146 3147 3148 3149 3150 3151 3152 3153 3154 3155 3156 3157 3158 3159 3160 3161 3162 3163 3164 3165 3166 3167 3168 3169 3170 3171 3172 3173 3174 3175 3176 3177 3178 3179 3180 3181 3182 3183 3184 3185 3186 3187 3188 3189 3190 3191 3192 3193 3194 3195 3196 3197 3198 3199 3200 3201 3202 3203 3204 3205 3206 3207 3208 3209 3210 3211 3212 3213 3214 3215 3216 3217 3218 3219 3220 3221 3222 3223 3224 3225 3226 3227 3228 3229 3230 3231 3232 3233 3234 3235 3236 3237 3238 3239 3240 3241 3242 3243 3244 3245 3246 3247 3248 3249 3250 3251 3252 3253 3254 3255 3256 3257 3258 3259 3260 3261 3262 3263 3264 3265 3266 3267 3268 3269 3270 3271 3272 3273 3274 3275 3276 3277 3278 3279 3280 3281 3282 3283 3284 3285 3286 3287 3288 3289 3290 3291 3292 3293 3294 3295 3296 3297 3298 3299 3300 3301 3302 3303 3304 3305 3306 3307 3308 3309 3310 3311 3312 3313 3314 3315 3316 3317 3318 3319 3320 3321 3322 3323 3324 3325 3326 3327 3328 3329 3330 3331 3332 3333 3334 3335 3336 3337 3338 3339 3340 3341 3342 3343 3344 3345 3346 3347 3348 3349 3350 3351 3352 3353 3354 3355 3356 3357 3358 3359 3360 3361 3362 3363 3364 3365 3366 3367 3368 3369 3370 3371 3372 3373 3374 3375 3376 3377 3378 3379 3380 3381 3382 3383 3384 3385 3386 3387 3388 3389 3390 3391 3392 3393 3394 3395 3396 3397 3398 3399 3400 3401 3402 3403 3404 3405 3406 3407 3408 3409 3410 3411 3412 3413 3414 3415 3416 3417 3418 3419 3420 3421 3422 3423 3424 3425 3426 3427 3428 3429 3430 3431 3432 3433 3434 3435 3436 3437 3438 3439 3440 3441 3442 3443 3444 3445 3446 3447 3448 3449 3450 3451 3452 3453 3454 3455 3456 3457 3458 3459 3460 3461 3462 3463 3464 3465 3466 3467 3468 3469 3470 3471 3472 3473 3474 3475 3476 3477 3478 3479 3480 3481 3482 3483 3484 3485 3486 3487 3488 3489 3490 3491 3492 3493 3494 3495 3496 3497 3498 3499 3500 3501 3502 3503 3504 3505 3506 3507 3508 3509 3510 3511 3512 3513 3514 3515 3516 3517 3518 3519 3520 3521 3522 3523 3524 3525 3526 3527 3528 3529 3530 3531 3532 3533 3534 3535 3536 3537 3538 3539 3540 3541 3542 3543 3544 3545 3546 3547 3548 3549 3550 3551 3552 3553 3554 3555 3556 3557 3558 3559 3560 3561 3562 3563 3564 3565 3566 3567 3568 3569 3570 3571 3572 3573 3574 3575 3576 3577 3578 3579 3580 3581 3582 3583 3584 3585 3586 3587 3588 3589 3590 3591 3592 3593 3594 3595 3596 3597 3598 3599 3600 3601 3602 3603 3604 3605 3606 3607 3608 3609 3610 3611 3612 3613 3614 3615 3616 3617 3618 3619 3620 3621 3622 3623 3624 3625 3626 3627 3628 3629 3630 3631 3632 3633 3634 3635 3636 3637 3638 3639 3640 3641 3642 3643 3644 3645 3646 3647 3648 3649 3650 3651 3652 3653 3654 3655 3656 3657 3658 3659 3660 3661 3662 3663 3664 3665 3666 3667 3668 3669 3670 3671 3672 3673 3674 3675 3676 3677 3678 3679 3680 3681 3682 3683 3684 3685 3686 3687 3688 3689 3690 3691 3692 3693 3694 3695 3696 3697 3698 3699 3700 3701 3702 3703 3704 3705 3706 3707 3708 3709 3710 3711 3712 3713 3714 3715 3716 3717 3718 3719 3720 3721 3722 3723 3724 3725 3726 3727 3728 3729 3730 3731 3732 3733 3734 3735 3736 3737 3738 3739 3740 3741 3742 3743 3744 3745 3746 3747 3748 3749 3750 3751 3752 3753 3754 3755 3756 3757 3758 3759 3760 3761 3762 3763 3764 3765 3766 3767 3768 3769 3770 3771 3772 3773 3774 3775 3776 3777 3778 3779 3780 3781 3782 3783 3784 3785 3786 3787 3788 3789 3790 3791 3792 3793 3794 3795 3796 3797 3798 3799 3800 3801 3802 3803 3804 3805 3806 3807 3808 3809 3810 3811 3812 3813 3814 3815 3816 3817 3818 3819 3820 3821 3822 3823 3824 3825 3826 3827 3828 3829 3830 3831 3832 3833 3834 3835 3836 3837 3838 3839 3840 3841 3842 3843 3844 3845 3846 3847 3848 3849 3850 3851 3852 3853 3854 3855 3856 3857 3858 3859 3860 3861 3862 3863 3864 3865 3866 3867 3868 3869 3870 3871 3872 3873 3874 3875 3876 3877 3878 3879 3880 3881 3882 3883 3884 3885 3886 3887 3888 3889 3890 3891 3892 3893 3894 3895 3896 3897 3898 3899 3900 3901 3902 3903 3904 3905 3906 3907 3908 3909 3910 3911 3912 3913 3914 3915 3916 3917 3918 3919 3920 3921 3922 3923 3924 3925 3926 3927 3928 3929 3930 3931 3932 3933 3934 3935 3936 3937 3938 3939 3940 3941 3942 3943 3944 3945 3946 3947 3948 3949 3950 3951 3952 3953 3954 3955 3956 3957 3958 3959 3960 3961 3962 3963 3964 3965 3966 3967 3968 3969 3970 3971 3972 3973 3974 3975 3976 3977 3978 3979 3980 3981 3982 3983 3984 3985 3986 3987 3988 3989 3990 3991 3992 3993 3994 3995 3996 3997 3998 3999 4000 4001 4002 4003 4004 4005 4006 4007 4008 4009 4010 4011 4012 4013 4014 4015 4016 4017 4018 4019 4020 4021 4022 4023 4024 4025 4026 4027 4028 4029 4030 4031 4032 4033 4034 4035 4036 4037 4038 4039 4040 4041 4042 4043 4044 4045 4046 4047 4048 4049 4050 4051 4052 4053 4054 4055 4056 4057 4058 4059 4060 4061 4062 4063 4064 4065 4066 4067 4068 4069 4070 4071 4072 4073 4074 4075 4076 4077 4078 4079 4080 4081 4082 4083 4084 4085 4086 4087 4088 4089 4090 4091 4092 4093 4094 4095 4096 4097 4098 4099 4100 4101 4102 4103 4104 4105 4106 4107 4108 4109 4110 4111 4112 4113 4114 4115 4116 4117 4118 4119 4120 4121 4122 4123 4124 4125 4126 4127 4128 4129 4130 4131 4132 4133 4134 4135 4136 4137 4138 4139 4140 4141 4142 4143 4144 4145 4146 4147 4148 4149 4150 4151 4152 4153 4154 4155 4156 4157 4158 4159 4160 4161 4162 4163 4164 4165 4166 4167 4168 4169 4170 4171 4172 4173 4174 4175 4176 4177 4178 4179 4180 4181 4182 4183 4184 4185 4186 4187 4188 4189 4190 4191 4192 4193 4194 4195 4196 4197 4198 4199 4200 4201 4202 4203 4204 4205 4206 4207 4208 4209 4210 4211 4212 4213 4214 4215 4216 4217 4218 4219 4220 4221 4222 4223 4224 4225 4226 4227 4228 4229 4230 4231 4232 4233 4234 4235 4236 4237 4238 4239 4240 4241 4242 4243 4244 4245 4246 4247 4248 4249 4250 4251 4252 4253 4254 4255 4256 4257 4258 4259 4260 4261 4262 4263 4264 4265 4266 4267 4268 4269 4270 4271 4272 4273 4274 4275 4276 4277 4278 4279 4280 4281 4282 4283 4284 4285 4286 4287 4288 4289 4290 4291 4292 4293 4294 4295 4296 4297 4298 4299 4300 4301 4302 4303 4304 4305 4306 4307 4308 4309 4310 4311 4312 4313 4314 4315 4316 4317 4318 4319 4320 4321 4322 4323 4324 4325 4326 4327 4328 4329 4330 4331 4332 4333 4334 4335 4336 4337 4338 4339 4340 4341 4342 4343 4344 4345 4346 4347 4348 4349 4350 4351 4352 4353 4354 4355 4356 4357 4358 4359 4360 4361 4362 4363 4364 4365 4366 4367 4368 4369 4370 4371 4372 4373 4374 4375 4376 4377 4378 4379 4380 4381 4382 4383 4384 4385 4386 4387 4388 4389 4390 4391 4392 4393 4394 4395 4396 4397 4398 4399 4400 4401 4402 4403 4404 4405 4406 4407 4408 4409 4410 4411 4412 4413 4414 4415 4416 4417 4418 4419 4420 4421 4422 4423 4424 4425 4426 4427 4428 4429 4430 4431 4432 4433 4434 4435 4436 4437 4438 4439 4440 4441 4442 4443 4444 4445 4446 4447 4448 4449 4450 4451 4452 4453 4454 4455 4456 4457 4458 4459 4460 4461 4462 4463 4464 4465 4466 4467 4468 4469 4470 4471 4472 4473 4474 4475 4476 4477 4478 4479 4480 4481 4482 4483 4484 4485 4486 4487 4488 4489 4490 4491 4492 4493 4494 4495 4496 4497 4498 4499 4500 4501 4502 4503 4504 4505 4506 4507 4508 4509 4510 4511 4512 4513 4514 4515 4516 4517 4518 4519 4520 4521 4522 4523 4524 4525 4526 4527 4528 4529 4530 4531 4532 4533 4534 4535 4536 4537 4538 4539 4540 4541 4542 4543 4544 4545 4546 4547 4548 4549 4550 4551 4552 4553 4554 4555 4556 4557 4558 4559 4560 4561 4562 4563 4564 4565 4566 4567 4568 4569 4570 4571 4572 4573 4574 4575 4576 4577 4578 4579 4580 4581 4582 4583 4584 4585 4586 4587 4588 4589 4590 4591 4592 4593 4594 4595 4596 4597 4598 4599 4600 4601 4602 4603 4604 4605 4606 4607 4608 4609 4610 4611 4612 4613 4614 4615 4616 4617 4618 4619 4620 4621 4622 4623 4624 4625 4626 4627 4628 4629 4630 4631 4632 4633 4634 4635 4636 4637 4638 4639 4640 4641 4642 4643 4644 4645 4646 4647 4648 4649 4650 4651 4652 4653 4654 4655 4656 4657 4658 4659 4660 4661 4662 4663 4664 4665 4666 4667 4668 4669 4670 4671 4672 4673 4674 4675 4676 4677 4678 4679 4680 4681 4682 4683 4684 4685 4686 4687 4688 4689 4690 4691 4692 4693 4694 4695 4696 4697 4698 4699 4700 4701 4702 4703 4704 4705 4706 4707 4708 4709 4710 4711 4712 4713 4714 4715 4716 4717 4718 4719 4720 4721 4722 4723 4724 4725 4726 4727 4728 4729 4730 4731 4732 4733 4734 4735 4736 4737 4738 4739 4740 4741 4742 4743 4744 4745 4746 4747 4748 4749 4750 4751 4752 4753 4754 4755 4756 4757 4758 4759 4760 4761 4762 4763 4764 4765 4766 4767 4768 4769 4770 4771 4772 4773 4774 4775 4776 4777 4778 4779 4780 4781 4782 4783 4784 4785 4786 4787 4788 4789 4790 4791 4792 4793 4794 4795 4796 4797 4798 4799 4800 4801 4802 4803 4804 4805 4806 4807 4808 4809 4810 4811 4812 4813 4814 4815 4816 4817 4818 4819 4820 4821 4822 4823 4824 4825 4826 4827 4828 4829 4830 4831 4832 4833 4834 4835 4836 4837 4838 4839 4840 4841 4842 4843 4844 4845 4846 4847 4848 4849 4850 4851 4852 4853 4854 4855 4856 4857 4858 4859 4860 4861 4862 4863 4864 4865 4866 4867 4868 4869 4870 4871 4872 4873 4874 4875 4876 4877 4878 4879 4880 4881 4882 4883 4884 4885 4886 4887 4888 4889 4890 4891 4892 4893 4894 4895 4896 4897 4898 4899 4900 4901 4902 4903 4904 4905 4906 4907 4908 4909 4910 4911 4912 4913 4914 4915 4916 4917 4918 4919 4920 4921 4922 4923 4924 4925 4926 4927 4928 4929 4930 4931 4932 4933 4934 4935 4936 4937 4938 4939 4940 4941 4942 4943 4944 4945 4946 4947 4948 4949 4950 4951 4952 4953 4954 4955 4956 4957 4958 4959 4960 4961 4962 4963 4964 4965 4966 4967 4968 4969 4970 4971 4972 4973 4974 4975 4976 4977 4978 4979 4980 4981 4982 4983 4984 4985 4986 4987 4988 4989 4990 4991 4992 4993 4994 4995 4996 4997 4998 4999 5000 5001 5002 5003 5004 5005 5006 5007 5008 5009 5010 5011 5012 5013 5014 5015 5016 5017 5018 5019 5020 5021 5022 5023 5024 5025 5026 5027 5028 5029 5030 5031 5032 5033 5034 5035 5036 5037 5038 5039 5040 5041 5042 5043 5044 5045 5046 5047 5048 5049 5050 5051 5052 5053 5054 5055 5056 5057 5058 5059 5060 5061 5062 5063 5064 5065 5066 5067 5068 5069 5070 5071 5072 5073 5074 5075 5076 5077 5078 5079 5080 5081 5082 5083 5084 5085 5086 5087 5088 5089 5090 5091 5092 5093 5094 5095 5096 5097 5098 5099 5100 5101 5102 5103 5104 5105 5106 5107 5108 5109 5110 5111 5112 5113 5114 5115 5116 5117 5118 5119 5120 5121 5122 5123 5124 5125 5126 5127 5128 5129 5130 5131 5132 5133 5134 5135 5136 5137 5138 5139 5140 5141 5142 5143 5144 5145 5146 5147 5148 5149 5150 5151 5152 5153 5154 5155 5156 5157 5158 5159 5160 5161 5162 5163 5164 5165 5166 5167 5168 5169 5170 5171 5172 5173 5174 5175 5176 5177 5178 5179 5180 5181 5182 5183 5184 5185 5186 5187 5188 5189 5190 5191 5192 5193 5194 5195 5196 5197 5198 5199 5200 5201 5202 5203 5204 5205 5206 5207 5208 5209 5210 5211 5212 5213 5214 5215 5216 5217 5218 5219 5220 5221 5222 5223 5224 5225 5226 5227 5228 5229 5230 5231 5232 5233 5234 5235 5236 5237 5238 5239 5240 5241 5242 5243 5244 5245 5246 5247 5248 5249 5250 5251 5252 5253 5254 5255 5256 5257 5258 5259 5260 5261 5262 5263 5264 5265 5266 5267 5268 5269 5270 5271 5272 5273 5274 5275 5276 5277 5278 5279 5280 5281 5282 5283 5284 5285 5286 5287 5288 5289 5290 5291 5292 5293 5294 5295 5296 5297 5298 5299 5300 5301 5302 5303 5304 5305 5306 5307 5308 5309 5310 5311 5312 5313 5314 5315 5316 5317 5318 5319 5320 5321 5322 5323 5324 5325 5326 5327 5328 5329 5330 5331 5332 5333 5334 5335 5336 5337 5338 5339 5340 5341 5342 5343 5344 5345 5346 5347 5348 5349 5350 5351 5352 5353 5354 5355 5356 5357 5358 5359 5360 5361 5362 5363 5364 5365 5366 5367 5368 5369 5370 5371 5372 5373 5374 5375 5376 5377 5378 5379 5380 5381 5382 5383 5384 5385 5386 5387 5388 5389 5390 5391 5392 5393 5394 5395 5396 5397 5398 5399 5400 5401 5402 5403 5404 5405 5406 5407 5408 5409 5410 5411 5412 5413 5414 5415 5416 5417 5418 5419 5420 5421 5422 5423 5424 5425 5426 5427 5428 5429 5430 5431 5432 5433 5434 5435 5436 5437 5438 5439 5440 5441 5442 5443 5444 5445 5446 5447 5448 5449 5450 5451 5452 5453 5454 5455 5456 5457 5458 5459 5460 5461 5462 5463 5464 5465 5466 5467 5468 5469 5470 5471 5472 5473 5474 5475 5476 5477 5478 5479 5480 5481 5482 5483 5484 5485 5486 5487 5488 5489 5490 5491 5492 5493 5494 5495 5496 5497 5498 5499 5500 5501 5502 5503 5504 5505 5506 5507 5508 5509 5510 5511 5512 5513 5514 5515 5516 5517 5518 5519 5520 5521 5522 5523 5524 5525 5526 5527 5528 5529 5530 5531 5532 5533 5534 5535 5536 5537 5538 5539 5540 5541 5542 5543 5544 5545 5546 5547 5548 5549 5550 5551 5552 5553 5554 5555 5556 5557 5558 5559 5560 5561 5562 5563 5564 5565 5566 5567 5568 5569 5570 5571 5572 5573 5574 5575 5576 5577 5578 5579 5580 5581 5582 5583 5584 5585 5586 5587 5588 5589 5590 5591 5592 5593 5594 5595 5596 5597 5598 5599 5600 5601 5602 5603 5604 5605 5606 5607 5608 5609 5610 5611 5612 5613 5614 5615 5616 5617 5618 5619 5620 5621 5622 5623 5624 5625 5626 5627 5628 5629 5630 5631 5632 5633 5634 5635 5636 5637 5638 5639 5640 5641 5642 5643 5644 5645 5646 5647 5648 5649 5650 5651 5652 5653 5654 5655 5656 5657 5658 5659 5660 5661 5662 5663 5664 5665 5666 5667 5668 5669 5670 5671 5672 5673 5674 5675 5676 5677 5678 5679 5680 5681 5682 5683 5684 5685 5686 5687 5688 5689 5690 5691 5692 5693 5694 5695 5696 5697 5698 5699 5700 5701 5702 5703 5704 5705 5706 5707 5708 5709 5710 5711 5712 5713 5714 5715 5716 5717 5718 5719 5720 5721 5722 5723 5724 5725 5726 5727 5728 5729 5730 5731 5732 5733 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<!--meta http-equiv="Content-Type" content="text/html; charset=utf-8" -->
<meta http-equiv="Content-Style-Type" content="text/css">
<meta http-equiv="Window-target" content="_top">
<meta name="description" content="ntop (http://www.ntop.org) FAQ file.">
<meta name="author" content="ntop">
<meta name="generator" content="ntop 5.0.1">
<title>ntop FAQ</title>
<script SRC="/functions.js" TYPE="text/javascript" LANGUAGE="javascript"></script>
<link rel="stylesheet" href="/style.css" TYPE="text/css">
<!--#include virtual="/menuHead.html" -->
</head>
<body link="blue" vlink="blue">
<!--#include virtual="/menuBody.html" -->
<h1>ntop FAQ...</h1>
<p>This is an unsophisticated, automated conversion of the source file, docs/FAQ into html.
Please report problems to the ntop-dev mailing list.
But remember, it's not about making it look good, it's about making the content available.</p>
<hr>
</p>
<h2>TOP 10 - the questions everyone asks...</h2>
<br>
<p><b>Q0.</b> I downloaded the source and ./configure doesn't work.</p>
<p><b>A.</b> Yup.</p>
<p> There is a long history of warfare between the versions of the GNU
autotools we use to build the distribution files and the ones installed
on your host. So during the 3.3 development cycle, Luca finally gave in
and stopped distributing a generated configure file.
</p>
<p> Instead there is a script, autogen.sh, which uses the version(s) of the
tools installed on your system to create configure and then run it.
</p>
<p> Yes, this means you MUST have the following tools installed:
</p>
<pre>
libtool
automake
m4
autoconf
</pre>
<p> We are talking only about people who are compiling from source. Those
tools are pretty much required for ANY source. Live with it.
</p>
<br>
<p><b>Q1(a).</b> Can I store data in a SQL database?</p>
<br>
<p><b>Q1(b).</b> When ntop stops I lose all my data. Why?</p>
<br>
<p><b>Q1(c).</b> Why doesn't the -S option work?</p>
<p><b>A.</b> ntop used to optionally store some data in a SQL database. The code was broken, difficult to maintain, etc. and was removed. A LONG TIME AGO.
If you are reading about this in 'some' documentation - update.
</p>
<p> Current ntop is 3.1, which is the only version we support.
</p>
<p> There are scripts that various users have offered to take the data dump
and insert it into a SQL database. Search the back traffic on the mailing
list for them.
</p>
<p> Yes, ntop uses memory based structures to hold usage data and they are lost
when you reset or restart ntop.
</p>
<p> Persistent storage is in the RRD databases - there's a paper @ SourceForge
that explains them.
</p>
<p> There was another option for some persistence - it was -S - look in FAQarchive
for an article about it, "What was the -S option?".
</p>
<br>
<p><b>Q2.</b> The archive isn't indexed, so I can't search it.</p>
<p><b>A.</b> Yes, but it's easy to search using search engines or mail archives.</p>
<p> Google: You need to restrict the search to the U of Pisa mail list
gateway, i.e.:
</p>
<pre>
site:listgateway.unipi.it ntop freebsd
</pre>
<p> Two 'mail archive' sites that I know of (as of March 2005) are:
</p>
<p> gmane: http://search.gmane.org (our lists are renamed as gmane.linux.ntop.general
and gmane.linux.ntop.devel).
</p>
<p> The Mail Archive:
</p>
<pre>
http://www.mail-archive.com/ntop-dev@unipi.it/
http://www.mail-archive.com/ntop@unipi.it/
</pre>
<br>
<p><b>Q3.</b> ntop crashed and the last log message is "xxxxx".</p>
<p><b>A.</b> Sorry, that's useless. ntop is multi-threaded and processes 100s or 1000s of packets per second. The last log message is probably from the wrong thread
and many seconds out of date.
</p>
<p> To capture the true 'failure point information', you need to run under the
debugger (gdb) and send us the various outputs. Instructions are at the bottom
of this document. Look for "GDB ultraMini-tutorial".
</p>
<p> Yes, you will need the source and a compiler.
</p>
<br>
<p><b>Q3(a).</b> What about the backtrace?</p>
<p><b>A.</b> Again, probably useless. Use gdb and capture the full failure point info. If you want to see more, look for "Q. What about the backtrace?" below.
</p>
<br>
<p><b>Q4.</b> I'm running out of memory.</p>
<p><b>A.</b> Basically ntop uses a lot of memory - it stores a chunk of information about each and every host it's monitoring. See "Q. Why does ntop use so much memory ?" and
the following articles below.
</p>
<br>
<p><b>Q5.</b> Dropped packets?</p>
<p><b>A.</b> There are lots of reasons - look for "Q. Why does ntop drop packets?" below. Short version, is that as long as it's random, the information you glean from ntop
(32% of our usage is P2P Music) is still valid. But you are probably understating
any problems.
</p>
<br>
<p><b>Q6.</b> The docs at ntop.org say ...</p>
<p><b>A.</b> Stop right there. They're out of date (notice, for example, the man page is July 2002?).
</p>
<p> The only current stuff is this FAQ (which gets out of date quickly) the other files
in the distribution and the mailing lists.
</p>
<p> You can access the updated FAQ from docs/FAQ in the cvs or from your ntop instance
(click on the (?) icon in the "About" menu and read down 1/2 a page or so.
</p>
<br>
<p><b>Q7.</b> How do I report a problem?</p>
<p><b>A.</b> Best way is to use the PR (Problem Report) form - it automatically includes a lot of the important information about your ntop instance. In the "About" menu, click on the
"Bug" icon. This generates a text form you can copy into your email program, update
and send.
</p>
<br>
<p><b>Q8.</b> HACK ALERT HACK ALERT - ntop is sending information to some machine called "jake".</p>
<p><b>A.</b> Chill. Take a deep breath.</p>
<p> Jake is the cannonical name for version.ntop.org. All you are seeing is the version
check. See "Q. What's with the version check?" below.
</p>
<br>
<p><b>Q9.</b> The program asks for password for "ntop HTTP server". When I started NTOP for the first time, it asked me to set admin password, and i put "xxxxxxxx". The user is "xxxxxxxxxx"
but I get "Unauthorized to access the document". Why?
</p>
<p><b>A.</b> The correct user to specify for the ntop web server is admin. The -u value in the command line or parameter file is the account ntop runs under.
</p>
<br>
<p><b>Q10.</b> I'm not getting any rrd output.</p>
<p><b>A.</b> First, make sure that the plugin is installed (you should see it in the web interface under plugins). Make sure it is configured and active.
</p>
<p> The default configuration does NOT include per-host .rrd files, because these can take
up a lot of space. But you probably want them and at the medium or high level of detail.
</p>
<br>
<p><b>Q11.</b> Single Threaded ntop?</p>
<p><b>A.</b> Gone. Poof. We're in a multi-threaded world, so live with it.</p>
<br>
<p><b>Q.</b> Where can I find ntop?</p>
<p><b>A.</b> The official website can be found at http://www.ntop.org/.</p>
<br>
<p><b>Q.</b> Where do I get the source?</p>
<p><b>A.</b> SourceForge -- http://sourceforge.net/projects/ntop/</p>
<p> There is also a cvs (current development) maintained at cvs.ntop.org.
(instructions are on the download page of www.ntop.org)
</p>
<br>
<p><b>Q.</b> What is ntop?</p>
<p><b>A.</b> ntop is an open source network top - it monitors a network and collects information about the protocols and hosts for display.
</p>
<br>
<p><b>Q.</b> Um, so it's like mrtg (http://people.ee.ethz.ch/~oetiker/webtools/mrtg/)?</p>
<p><b>A.</b> Yes and no...</p>
<p> Yes in that both are analyzers of network packets.
</p>
<p> Yes in that both display information about your network.
</p>
<p> No in that they take very different approaches to collecting information.
</p>
<p> No in that they display different types of information.
</p>
<br>
<p><b>Q.</b> So mrtg...</p>
<p><b>A.</b> mrtg creates a picture of the network centered on the device on the link between devices (and aggregations of devices and links).
</p>
<p> Tobias (Tobi) Oetiker describe mrtg as:
</p>
<pre>
"The Multi Router Traffic Grapher (MRTG) is a tool to monitor
the traffic load on network-links. MRTG generates HTML pages
containing graphical images which provide a LIVE visual
representation of this traffic."
</pre>
<br>
<p><b>Q.</b> And mrtg works how?</p>
<p><b>A.</b> mrtg reads the counters maintained by various devices such as routers, using a protocol called 'snmp' (Simple Network Monitoring Protocol). The
management information bases (MIBs) read using snmp, contain incredibly
detailed information about the packets the device has seen and what it has
done with them.
</p>
<p> Again, quoting Tobi:
</p>
<pre>
"MRTG ... uses SNMP to read the traffic counters of your routers and
... which logs the traffic data and creates beautiful graphs representing
the traffic on the monitored network connection."
</pre>
<p> mrtg is focused on 'layer 2' (the tcp/ip and other low level protocol).
</p>
<br>
<p><b>Q.</b> And ntop?</p>
<p><b>A.</b> ntop doesn't use snmp for it's main analysis - it's not a device centric view of the network. Instead ntop actually processes the network packets
directly.
</p>
<br>
<p><b>Q.</b> What's wrong with snmp?</p>
<p><b>A.</b> Nothing. As of 3.1, ntop has some sort of snmp plugin.</p>
<p> It's just different.
</p>
<p> snmp is a pull protocol, that is a monitoring tool has to pull the
information from the device. snmp has 'traps' that is alert messages which
can be sent out, but the MIB data has to be read by the monitoring tool from
the device.
</p>
<p> snmp is an older protocol, from the dawn of the network era and it has some
minor issues of security and complexity and verbosity. But it's a critical
network protocol, used successfully by 1000s of ISPs to monitor AND CONTROL
vast networks.
</p>
<p> From our perspective, the problems with snmp are minor -
</p>
<p> It can use a lot of bandwidth - especially if you're reading from devices
on the far side of slow links.
</p>
<p> Pulling data out of MIBs is a complex process. MIBs can be specified in
an RFC, or be unique to a vendor/device.
</p>
<p> An snmp-based tool either has to restrict itself to the common MIBs,
or (most often for vendor tools) it be updated whenever a new device
must be supported or a MIB changes.
</p>
<p> This makes snmp-based tools complex, because data may be unavailable
in certain versions of seemingly similar devices, etc. For example,
http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
is a page which links to the specific MIBs supported by various
Cisco devices.
</p>
<br>
<p><b>Q.</b> So why hasn't ntop 'won'?</p>
<p><b>A.</b> mrtg excels at monitoring 100s or 1000s of network devices (routers, switches, etc.) and presenting that information over long periods of time.
</p>
<p> ntop doesn't do a good job of showing multiple 'networks' - it's really
focused on aggregating a picture of a single network. And for drilling down
into that picture or presenting it over long periods of time.
</p>
<p> The processing of packets requires a lot more computer resources than just
reading counters from devices. On the plus side, this gives much more
detailed information - for example ntop sees the actual web server request
instead of just that there was traffic on port 80. On the minus side, it's
pretty easy to exceed the processing power of the low end machine typically
available for ntop. An ISP using ntop to monitor a couple of T3s needs a
FAST computer and A LOT of memory.
</p>
<p> ntop also requires access to the physical network (either directly via a
network card or indirectly via a netFlow/sFlow probe). This limits ntop's
(usefullness|ability) to work across sites.
</p>
<p> Once you learn what they do (mrtg and ntop), you'll probably discover that
You need both.
</p>
<br>
<p><b>Q.</b> What's this 'layer' crud?</p>
<p><b>A.</b> Network layers come from a widely cited but never implemented model, the OSI (Open System Interconnect ) networking model from the ISO (International
Standards Organization).
</p>
<p> Google for it - for example
</p>
<pre>
http://www.ussg.iu.edu/usail/network/nfs/network_layers.html
</pre>
<br>
<p><b>Q.</b> So ntop is like netFlow (Cisco), sFlow (RFC 3176, http://www.sflow.org) or RMON (HP)?
</p>
<p><b>A.</b> Not really, actually those are all protocols for sending and receiving information about the network.
</p>
<p> ntop has lots in common with the tools that USE those protocols.
</p>
<p> And there are lots of tools - some proprietary, many open source.
</p>
<p> The devices/programs that collect the information and send it out in netFlow,
sFlow or RMON format are usually called (by me) 'probes'. The devices and/or
programs that receive the netFlow, sFlow or RMON formatted information and do
things with it are called 'collectors' (if they process it and forward it on)
or called 'displays'.
</p>
<p> In fact, ntop can receive netFlow packets and both send and receive sFlow
packets. It can be a 'probe' or a 'display'. (ntop used to be able to send
netFlow packets - that was removed 2004-03 by Luca).
</p>
<br>
<p><b>Q.</b> So ntop is like Nagios or Ipswitch's - WhatsUp Gold?.</p>
<p><b>A.</b> Nope - those are layer 4 and higher (application) monitoring programs.</p>
<br>
<p><b>Q.</b> So it's like ...</p>
<p><b>A.</b> Enough already - if you search Freshmeat.net, http://freshmeat.net/search/?q=network+monitor§ion=projects
you will find (as of 18Aug2003):
</p>
<pre>
Topic :: System :: Networking :: Monitoring (654 projects)
</pre>
<p> We'll be here all day. ntop is ntop.
</p>
<br>
<p><b>Q.</b> Ok, so ntop is a unique TCP/IP analyzer.</p>
<p><b>A.</b> Not exactly.</p>
<p> First off, ntop pretty much doesn't care about the lowest (layer 1 or wire)
layer. It leaves dealing with that to a library, libpcap, which hides most
of that.
</p>
<p> ntop is designed as a hybrid packet analyzer, not a pure Ethernet analyzer
(layer 2) nor a pure TCP/IP analyzer (layer 3).
</p>
<p> ntop gets the data at the layer 2 (frame) level, which could be Ethernet
or another protocol. Beyond Ethernet, ntop has minimal smarts about FDDI,
PPP, RAW and TOKEN-RING frames. That is, at least enough for some basic
counts or to extract the (layer 3) TCP/IP data in side.
</p>
<p> ntop 3.0 adds TWO (three?) HUGE areas of new protocol support.
</p>
<p> ntop 3.0 supports IPv6, thanks to code contributed by Olivier Festor
<Olivier.Festor@loria.fr> and Abdelkader Lahmadi <Abdelkader.Lahmadi@loria.fr>
of the MADYNES Research Time (Managing DYnamic NEtworks and Services), see
http://madynes.loria.fr/.
</p>
<p> ntop 3.0 has more than a fair amount of smarts about FibreChannel and SCSI
thanks to code contributed by Dinesh G Dutt <ddutt@cisco.com> of Cisco.
</p>
<p> However, since most of ntop's displayed counts are at the TCP/IP level, it
confuses people into thinking ntop is purely a TCP/IP analyzer.
</p>
<p> ntop is a traffic monitor with it's own network interfaces, which monitors
what it sees (or is told about through netFlow or sFlow probes).
</p>
<br>
<p><b>Q.</b> ntop runs under?</p>
<p><b>A.</b> ntop is known to work under Linux, Mac OS X, FreeBSD, Solaris and Win32.</p>
<p> ntop development is done primarily on Fedora Linux.
</p>
<p> Luca also does a port to Win32 (MS Visual C .Net) and used to work in the Sun
Solaris environment. He also seems to work with FreeBSD 5.4.
</p>
<p> I (Burton) usually work under Fedora Linux, but use Microsoft's VPC 2004 and
VMware Workstation 5 to test under other Linux distros and OSes.
</p>
<p> Our users run under many other platforms - Here's data from the version.xml log
records showing what people were running while testing 3.2:
</p>
<p> (This data covered approximately the first two weeks of July 2005)
</p>
<pre>
count version
------- -------
16684 3.1
10960 3.0
345 3.1rc1
259 3.1.1
etc.
</pre>
<pre>
count OS Version
------- ------- --------------
20509 Linux
3566 Windows WinNT/2K/XP
1752 Unknown Windowsv3.1
1018 Unknown Windowsv3.0
266 FreeBSD 5.3
234 FreeBSD 5.4
219 Darwin 7.7.0
</pre>
<p> Of course, this is self-selected - people can turn off the logging.
</p>
<p> Linux covers lots of Different Linuxes... of the ones we recognize:
</p>
<pre>
count Distro Release
------- --------- --------
3148 suse
2637 redhat 9
2625 fedora 3
2014 fedora 2
1541 debian 3.1
1373 gentoo 1.4.16
613 redhat 3
603 fedora 1
523 mandrakel 10.2
505 gentoo 1.6.12
473 redhat 7.3
448 mandrakel 10.1
428 debian
399 redhat 4
367 redhat 8.0
301 slackware 10.1.0
282 slackware 10.0.0
</pre>
<p> The jump in 'SuSE' may represent nothing more than improved detection
in the 3.2/3.1 scripts vs. 3.0. We used to have a huge 'unknown' count.
</p>
<pre>
Running under pretty much any *nix is at least theoretically possible.
But it takes interested party/parties and access to resources - some of the
things that ntop does such as libpcap and loading plugins are tied tighter
to the OS than you might like.
</pre>
<pre>
There are sections below about each specific OS.
</pre>
<h2>Features</h2>
<br>
<p><b>Q.</b> What determines the features of ntop?</p>
<p><b>A.</b> <laugh>Whatever Luca wants</laugh></p>
<br>
<p><b>Q.</b> Why did you do this "x" instead of feature "y"?</p>
<p><b>A.</b> Don't know. I could guess...</p>
<p> Imagine you are the network manager for a large University network and have
to crack down on users who are illegally exchanging copyrighted files or
using University resources to run a business without paying for the resources
being consumed.
</p>
<p> or
</p>
<p> You are a major vendor of infrastructure, whose customers are using networks
for new features such as storage area networks and you want to give them
the ability to monitor these.
</p>
<p> or
</p>
<p> You have a really cool technology that you've just donated to the community
via an RFC and wish to jump-start adoption of it.
</p>
<p> or
</p>
<p> You are moving heavily into IPv6 and need to be able to monitor your 'new'
network just like you monitored the IPv4 one.
</p>
<p> or (my favorite)
</p>
<p> You really, really, really hate that ntop generates such lousy html code
and you decide to scratch that itch.
</p>
<p> or (what should happen)
</p>
<p> A major corporation, with out resources, time, skills and/or inclination
to do it themselves sponsors the development of a feature that's critical
to him/her.
</p>
<p> or
</p>
<p> Then again, it could just be because it's cool...
</p>
<br>
<p><b>Q.</b> Could ntop do "x"</p>
<p><b>A.</b> Probably - as long as it doesn't move the tool away from it's purpose and it's strengths, almost anything is possible - especially as a plugin.
</p>
<br>
<p><b>Q.</b> Will you do "x"</p>
<p><b>A.</b> Maybe - if it's of interest to a developer, or you provide the code such that it can be merged in, or if you're willing to sponsor the development
effort (contact us through http://www.ntop.org/consultancy.html).
</p>
<h2>Documentation</h2>
<br>
<p><b>Q.</b> Why isn't there (any)(more)(better) documentation.</p>
<p><b>A.</b> (A personal peeve from Burton...)</p>
<p> I get real tired of people complaining that there isn't any documentation
and then being unwilling to contribute even the simplest stuff. I've said
I'll edit and assemble whatever people send me... and since I started working
with ntop in November 2001, I've received maybe six pages of stuff.
</p>
<p> I'm trying to get people - who aren't coders - to contribute to ntop the
project. The contribution that ANYONE can make is "documentation". A task-
specific HOWTO... some sample screen shots... An FAQ entry...
</p>
<p> I've tried being nice.
I've tried asking.
I've tried shaming people into it.
</p>
<p> What have I gotten? Zip.
</p>
<p> Nasty is all that's left... This is your fair warning. If you show up on
the ntop mailing lists and complain about documentation, you will get
blasted.
</p>
<p> -----Burton
</p>
<br>
<p><b>Q.</b> Ok, where can I find what does exist.</p>
<p><b>A.</b> http://www.ntop.org has pointers and some (very out-dated) documents.</p>
<p> The documentation in the docs/ directory, the Documentation files at SourceForge
and some at http://www.ntopsupport.com are basically all that there is.
</p>
<p> Search the ntop mailing lists at gmane, http://search.gmane.org. The lists
are called gmane.linux.ntop.general and gmane.linux.ntop.devel.
</p>
<p> Please contribute to the ntop community by writing things up for inclusion
in this FAQ or other documents!
</p>
<br>
<p><b>Q.</b> I can't find a file at SourceForge!</p>
<p><b>A.</b> You can reach the archives through any SourceForge mirror, or the main site:</p>
<pre>
http://prdownloads.sourceforge.net/n/nt/ntop
</pre>
<p> It has ALL the files unless we explicitly delete them...
</p>
<h2>Problems</h2>
<br>
<p><b>Q.</b> I have a problem...</p>
<p><b>A.</b> Make sure it's a supported release!</p>
<p> We support only the current versions of ntop. This is either:
</p>
<pre>
* the last release, e.g. v3.1.
* the current cvs (cvs.ntop.org)
* the latest development version posted at SourceForge (if one)
</pre>
<p> If you use a port/package and the latest version available for your
OS is some release candidate from a year ago, sorry. Contact the
packager and ask them to get current.
</p>
<p> Luca usually asks people to try the latest cvs (development) version
because problems are frequently already fixed in there.
</p>
<br>
<p><b>Q.</b> I'm running something supported and I've tried the latest & greatest. Still, I have a problem.
</p>
<p><b>A.</b> Read the ntop mailing lists.</p>
<p> The ntop mailing lists are at
</p>
<pre>
http://listgateway.unipi.it/mailman/listinfo/ntop
http://listgateway.unipi.it/mailman/listinfo/ntop-dev
and
http://listgateway.unipi.it/mailman/listinfo/ntop-misc
</pre>
<p> If you're having non-user problems OR you are using the cvs, you should be
reading and posting ntop-dev (for example, the cvs commit messages are posted
there). Stuff unrelated to baseline ntop (PF_RING) belongs in ntop-misc.
</p>
<p> You can read the lists through gmane (or other gateways) if you don't
want to subscribe, but only subscribers can post.
</p>
<p> You can download the older messages in large chunks from the mailing list
subscription pages. Look for "To see the collection of prior postings to
the list".
</p>
<br>
<p><b>Q.</b> I looked and I didn't find my problem.</p>
<p><b>A.</b> Join the mailing list(s) and ask for help.</p>
<p> Before you post, check the "HowTo Ask for Help" at the end of this FAQ.
</p>
<p> Please, if at all possible, use the built in PR_ form (the little 'bug' icon
on the 'About' tab).
</p>
<p> Guidelines for asking questions:
</p>
<p> ONE and only ONE problem / issue / question per message.
</p>
<p> With a meaningful subject.
</p>
<pre>
The goal is that if you're asking a common question, the
subject would have allowed you to find it in the back
traffic for the mailing list.
</pre>
<p> Post the information about your environment we ask for.
</p>
<pre>
We STRONGLY suggest you use the automatically generated "Problem
Report" form that since it contains much of the necessary information.
</pre>
<p> Make sure you're in a supported environment (./configure --showoses).
</p>
<pre>
If it's an unsupported environment, we're interested in your efforts to
make ntop work, but we don't have the time, resources, knowledge and/or
interest to do it ourselves.
</pre>
<p> For software 'crashes', please run ntop under the gdb debugger and capture
the full failure information.
</p>
<pre>
Brief instructions on using gdb are at the end of this file (docs/FAQ).
</pre>
<br>
<p><b>Q.</b> I posted to the list and nobody answered me.</p>
<p><b>A.</b> ntop is open source, and the lists are a community resource. If nobody answered your question, then nobody knew the answers off-hand and nobody
wanted to spend THEIR time solving YOUR problem.
</p>
<br>
<p><b>Q.</b> Do you offer paid support?</p>
<p><b>A.</b> Yes - contact us through http://www.ntop.org/consultancy.html</p>
<h2>Configuring ntop</h2>
<br>
<p><b>Q.</b> What does ./configure do?</p>
<p><b>A.</b> ./configure checks for the tools installed on your system - configuring ntop to compile with the ones you have and skip the ones you don't (or
to tell you if you're missing something critical).
</p>
<br>
<p><b>Q.</b> Why bother - just compile the code.</p>
<p><b>A.</b> Then you would have to have a machine configured EXACTLY like Luca's. Nothing else would work. Various OSes and Linux distributions package
the files in different ways and put them in different places. Plus some
packages put files into directories with release information in them, etc.
</p>
<br>
<p><b>Q.</b> OK, so ./configure</p>
<p><b>A.</b> Is how you tell ntop where to find things. A lot of stuff it can figure out on it's own, but if things get put in 'strange' places, ntop's
./configure has switches you use to tell where to find things.
</p>
<br>
<p><b>Q.</b> And the list is?</p>
<p><b>A.</b> ./configure --help shows the whole list. It's a bit confusing because there are standard options and ntop options mixed in there.
</p>
<p><b>A.</b> So, first let's look at the 'where are things' options. There are two types of files ntop is looking for, '.h' files and libxxxx files.
</p>
<p> .h files are also called 'includes' and libxxxx files are called libraries
or lib files.
</p>
<p> .h files are the C source for functions provided by the OS or by libraries.
They are typically in a directory named /usr/include, but they can be
placed ANYWHERE.
</p>
<p> lib files are compiled libraries of these functions (the .h tells ntop
how to call something, the lib file is the actual code). Their names
usually begin libxxxx (so the library gd is named libgd).
</p>
<p> By convention, libraries end in .so or .a. A .so library is a shared
library (Windows DLL), where one copy of the library is used by all
programs that want it's functions. A .a library is a non-shared or
static library, which must be merged (the technical term is linked)
with the code.
</p>
<p> ntop uses both - the myrrd library is a static, .a library. When it
comes to things like libpcap or libgd, we use shared (.so) libraries.
</p>
<p> Library files are typically placed in /usr/lib, where the gnu linker
(ld), 'knows' automatically how to find them. However, from OS to
OS and distribution to distribution, there are many other common places.
Some OSes even have a file telling ld all the places to look.
</p>
<br>
<p><b>Q.</b> So ntop looks for these .h and library thingies in a couple of places. What if it doesn't find them?
</p>
<p><b>A.</b> If a basic ./configure can't find something, you'll have to tell ntop where to look.
</p>
<p> It's complex and OS/distro dependent. For example, if you install libgd
from the Sun Freeware site on to a Solaris machine, the files get put
into /usr/local/include and /usr/local/lib, which are not on the lists
of 'standard' places for Solaris' versions of gcc (the Gnu c compiler)
or ld. So to compile ntop, you have to tell gcc to look in these
additional locations.
</p>
<p> The things ntop might be looking for are in this part of the
./configure --help output:
</p>
<pre>
+-External-source-locations:-------------------------------------------------+
--with-pcap-root=DIR LBNL pcap located in DIR
--with-pcap-lib=DIR or libpcap located in DIR
--with-pcap-include=DIR or pcap.h located in DIR
--with-gdbm-root=DIR gdbm located in DIR
--with-gdbm-lib=DIR or libgdbm located in DIR
--with-gdbm-include=DIR or gdbm.h located in DIR
--with-zlib-root=DIR zlib located in DIR
--with-zlib-lib=DIR or libz located in DIR
--with-zlib-include=DIR or zlib.h located in DIR
--with-gd-root=DIR gd located in DIR
--with-gd-lib=DIR or libgd located in DIR
--with-gd-include=DIR or gd.h located in DIR
--with-libpng-root=DIR libpng located in DIR
--with-libpng-lib=DIR or libpng located in DIR
--with-libpng-include=DIR or png.h located in DIR
--with-ossl-root=DIR openSSL located in DIR
--with-ossl-lib=DIR or libssl located in DIR
--with-ossl-include=DIR or ssl.h located in DIR
--with-localedir=DIR LOCALE files located in DIR (i18n)
+-----------------------------------------------------------------------+
</pre>
<p> You can see that there is a pattern, pretty much every --with-xxxxx-root
has a --with-xxxxx-include and --with-xxxxx-lib option.
</p>
<p> So, if ntop tells you it can't find something, do this - first look for the
File on your system:
</p>
<pre>
$ locate pcap.h
/usr/include/pcap/pcap.h
</pre>
<p> (If you don't have locate, this works too:
</p>
<pre>
$ find / -type f -name "pcap.h"
)
</pre>
<p> And then tell ./configure via --with-pcap-include=/usr/include/pcap
</p>
<p> (Some OSes are smart enough to look in a subdirectory of the standard
location, but others aren't).
</p>
<br>
<p><b>Q.</b> Ok, but why three options?</p>
<p><b>A.</b> You use either the --with-xxxxx-root option OR either/both of the others at a time. But ntop really only looks at the --with-xxxxx-include and
--with-xxxxx-lib options.
</p>
<p> Internally, --with-xxxxx-root=/a/b/c is translated into
--with-xxxxx-lib=/a/b/c/lib and --with-xxxxx-include=/a/b/c/include
(that's the usual pattern).
</p>
<p> Now sometimes libraries are installed logically - if the pcap.h file is in
/usr/local/pcap/include, the library (libpcap.so) is probably in
/usr/local/pcap/lib. Sometimes they are not logical and you will have
to use the split options.
</p>
<p> The --with-pcap-root=/usr/local/pcap is shorthand for the two options,
--with-pcap-include=/usr/local/pcap/include and
--with-pcap-lib=/usr/local/pcap/lib.
</p>
<br>
<p><b>Q.</b> Oh Ghu - aren't there any short cuts.</p>
<p><b>A.</b> For the first time you try ./configure, there's a script on SourceForge in The user contributed area that will try to build the ./configure line for
you.
</p>
<br>
<p><b>Q.</b> And the OTHER options</p>
<p><b>A.</b> There is a set that tells ntop where to install stuff. For simplicity, the two you might want to change are:
</p>
<pre>
--prefix=PREFIX install architecture-independent files in PREFIX
[/usr/local]
--datadir=DIR read-only architecture-independent data
[PREFIX/share]
</pre>
<p> --prefix tells ntop where to install the various files. The default value
is /usr/local, which is where most non-OS software normal goes.
</p>
<p> A common choice for libraries (such as pcap) is --prefix=/usr, which puts
things like .h files in places easier to automatically find (/usr/include).
--prefix=/usr certainly works for ntop. --prefix=/opt is another choice.
</p>
<p> The 'proper' choice turns on which model of file organization the OS and
sysadmin prefer. That's a fight I'm staying out of.
</p>
<p> --datadir tells ntop where to put its databases and output files. The
default is /usr/share/ntop, but that will give some sysadmin's agita.
Another popular choice is --datadir=/var, which puts all the files in
/var/ntop. That may be attractive especially if you make /var/ntop
a separate partition, so the rrd files don't eat all your disk space.
</p>
<br>
<p><b>Q.</b> What's --enable-iknowbetter Override WILLFAIL</p>
<p><b>A.</b> There are some error messages where it's possible that thing work (now) that didn't used to, or you're doing development and don't want ntop
to stop you from doing something, or there's an error message that you
have skipped before without getting bitten.
</p>
<p> --enable-iknowbetter will print the message but not stop ntop from
finishing ./configure.
</p>
<p> Use it at your own risk.
</p>
<br>
<p><b>Q.</b> What are the --enable and --disable options?</p>
<p><b>A.</b> These (and the with/without options) pretty much do what you think - they enable or disable large chunks of ntop functionality:
</p>
<pre>
+--ntop-specific:------------------------------------------------------------+
--enable-sslv3 enable ssl v3 support [default=disabled]
--enable-sslwatchdog enable Watchdog for ssl hangups [default=disabled]
--disable-plugins disable compilation of plugins [default=enabled]
--enable-static-plugins Enable static linked plugins sntop, default=dynamic]
--enable-ignoresigpipe Ignore SIGPIPE errors [default=do not ignore]
--disable-snmp Disable SNMP support [default=disable]
--enable-i18n Enable (limited) internationalization [default=disabled]
--enable-jumbo-frames Enable Jumbo (9K) Ethernet frames [default=disabled]
--disable-ipv6 use IPv6 [default=enabled]
+-----------------------------------------------------------------------+
</pre>
<pre>
+--external-packages:---------------------------------------------------+
--without-ssl disable HTPPS support [default=enabled]
--without-zlib disable zlib [default=enabled]
--with-tcpwrap enable use of TCP Wrapper [default=disabled]
+-----------------------------------------------------------------------+
</pre>
<br>
<p><b>Q.</b> What ELSE?</p>
<p><b>A.</b> There are some so called 'environment variables' you can set that change things too. The common ones are:
</p>
<pre>
CC C compiler command
CFLAGS C compiler flags
LDFLAGS linker flags, e.g. -L<lib dir> if you have libraries in a
nonstandard directory <lib dir>
CPPFLAGS C/C++ preprocessor flags, e.g. -I<include dir> if you have
headers in a nonstandard directory <include dir>
CPP C preprocessor
</pre>
<p> You would use these variables to override the choices made by ./configure
or to help it to find libraries and programs with truly nonstandard
names/locations.
</p>
<p> The best place to look for examples of these environment variables are in
the OS/distribution files in the configureextra directory. For example,
(again picking on Solaris), we use LDFLAGS to tell ld to look in some
common Solaris locations for libraries via this:
</p>
<pre>
LDFLAGS="-L/usr/local/lib -R/usr/local/lib ${LDFLAGS}"
</pre>
<p> What that does is add /usr/local/lib to the locations that ld will check.
</p>
<br>
<p><b>Q.</b> ./configure dies in some strange horrible way complaining about version conflicts, lunar phase or whatever.
</p>
<p><b>A.</b> The process of creating portable cross-platform scripts for building software is ugly and hard and prone to failure. There are tools
(released by gnu) to help, named automake, autoconf and libtool.
(Collectively the auto* tools).
</p>
<p> These tools take basic files and generate more complex files based
on a series of rules, conventions and macros (much of which is poorly
or undocumented). Other processes (e.g. ./configure) take these files
and generate more complex files based on a different series of rules,
conventions and macros. This ultimately produces the 'Makefile', which
a program called make uses - based on (...wait for it...) yet another
series of rules, conventions and macros - to actually compile the ntop
source.
</p>
<p> There are interdependencies among the tools, partial support for older
versions in some releases, but not in other releases and many more
problems.
</p>
<p> Different OSes and different Linux distros ship with wildly different
versions. Some even have scripts that attempt to analyze the file and
pick the correct version (which just means that trying to code a file
with multiple version support confuses the tool).
</p>
<p> So if you have a basic, total failure of ./configure, it's usually
the auto* tools.
</p>
<p> ntop used to ship with a manual script that rebuilt the generated files
according to the version(s) of the tools installed on the system you were
using to build ntop. Thus the standard answer was 'run ./autogen.sh -1'.
</p>
<p> But, this meant that you had to have these 'developer' tools installed
and caused much problems and gnashing of teeth.
</p>
<p> So we spent 100s of hours rebuilding the scripts to be totally independent
of having the tools installed on your system - only to run into problems
because the xyz 1.6.1 tool installed by default on OS A isn't quite
compatible with the 1.6.3 version on OS B.
</p>
<p> So we put technology in place to automatically detect tool versions and
rebuild the generated files if necessary. That meant you had to have
these 'developer' tools installed and caused much problems.
</p>
<p> So we rebuilt the scripts AGAIN and AGAIN, dropped support for old versions
of the tools and finally reached a point where it works for most reasonably
current platforms. This is a compromise:
</p>
<pre>
Systems that don't have the tools installed usually work.
Systems that have bleeding edge versions of these tools may break.
Systems with very old versions also may break.
</pre>
<p> The technology to detect versions and rebuild the script files if
appropriate is still in there, but it's disabled from normal use.
</p>
<p> If you have the auto* tools installed and have ./configure problems, you
can activate the automatic rebuild feature via:
</p>
<pre>
$ export NTOPAUTOREBUILD=yes
$ ./configure ...
</pre>
<p> If the rebuild fixes it, that's great. Regardless, please report the
problem to the ntop mailing list. Please don't paraphrase the messages
cut & paste the ACTUAL MESSAGES into your report. Also, please let us
know the version(s) of the tools installed on your system:
</p>
<pre>
$ aclocal --version
$ autoheader --version
$ autoconf --version
$ automake --version
$ libtool --version
</pre>
<br>
<p><b>Q.</b> I can't build ntop... (auto* tools)</p>
<p><b>A.</b> ntop has been tested with and developed for various versions of the "GNU auto* tools" (automake, autoconf and libtool).
</p>
<p> The basic requirements are
</p>
<p> automake 1.6.1 or higher (automake 1.4 and 1.5 may or may not work)
autoconf 2.51 or higher (autoconf 2.13 will NOT work)
libtool 1.4 or higher
</p>
<p> But that simple statement hides a lot of complexity and many potential
problems. Surprisingly, this isn't solely ntop's fault, it's the
combination of GNU auto* tools version to version compatiblity and
because we're trying to distribute configure and make files that work
on all versions. If ntop were less complex or less clever about
trying to build a working program even with many components missing,
things would work a lot better.
</p>
<p> The big change between autoconf 2.13 and 2.5x generated scripts is that
the ./configure and make steps are supposed to run the auto* commands
automatically if they're required. As we've seen, this doesn't always
work!
</p>
<p> If you run into problems, you can ALWAYS recreate the generated files
via this procedure:
</p>
<pre>
rm -f acinclude.m4 aclocal.m4 Makefile.in config.h.in configure Makefile
</pre>
<pre>
find current versions of libtool, config.guess and config.sub and cp
them into your working directory.
</pre>
<pre>
cat acinclude.m4.ntop libtool.m4.in > acinclude.m4
aclocal
autoheader
autoconf
automake --gnu --copy --add-missing
</pre>
<p> and then:
</p>
<pre>
./configure ...
make
make install
</pre>
<p> as usual.
</p>
<br>
<p><b>Q.</b> But how does it all hang together?</p>
<p><b>A.</b> There's a vsd (Visio)/pdf in the docs directory - ntop-autotools.pdf.</p>
<h2>Compiling ntop</h2>
<br>
<p><b>Q.</b> Which packages/libraries do I need to compile ntop:</p>
<pre>
Note: In some cases the minimal header files for a tool will be in
one "package" and the execution library in another. ntop needs
both so that the ./configure test finds the tool. It's usually
safest to install both the tool and development packages!
</pre>
<pre>
(Some packages will have additional packages as pre-requisites)
</pre>
<pre>
gdbm (We have people using 1.7.3, 1.8.0, 1.8.2 and 1.8.3)
</pre>
<pre>
libpcap
We recommend 0.8.3, but ntop works with most 0.7.2 and later versions.
</pre>
<pre>
STAY AWAY from older versions, especially under Linux.
</pre>
<pre>
Note: Building libpcap requires: bison/flex
</pre>
<pre>
gd
http://www.boutell.com/gd/gd.html - note that many distros have both
the 1.8.x and 2.x series installed for differnt packages that require
them. This occasionally causes problems.
</pre>
<pre>
libpng (1.2.x - although ntop works with 1.0.x versions, the two libpng
versions are not compatible and will often cause version conflicts
and crashes).
</pre>
<pre>
glibc
</pre>
<pre>
cpp
</pre>
<pre>
gcc most versions of gcc should work, but there are no promisses.
</pre>
<pre>
libtool 1.4+ (distribution is built with 1.4.2)
(there are successes reported with 1.3.4 or 1.3.5 -
use --enable-iknowbetter)
</pre>
<pre>
gawk/mawk
Note: If all you have is original awk, then ./configure will not work.
</pre>
<br>
<p><b>Q.</b> Will the "xyz" compiler work instead of gcc?</p>
<p><b>A.</b> We explicitly REQUIRE gcc.</p>
<p> We know that under many systems, a compiler called cc is available. On some,
it's a symbolic link to gcc, BUT, when invoked as cc, it often triggers 'old'
behaviors for cc compatibility. On others, cc is a retarded compiler just good
enough for compiling the kernel.
</p>
<p> The one exception is Sun's cc, which - since Luca used to do a lot of development
on Solaris - was pretty well supported.
</p>
<br>
<p><b>Q.</b> The auto* tools?</p>
<p><b>A.</b> Only if you are going to rebuild the distributed script files:</p>
<pre>
autoconf 2.5+ (distribution with 2.57)
automake 1.6+ (distribution with 1.8.3)
</pre>
<br>
<p><b>Q.</b> Optional libraries?</p>
<p><b>A.</b> Lots. The most common is:</p>
<pre>
openssl (for https:// support)
Note: For security reasons you should only have the most current
Version of openssl installed.
</pre>
<br>
<p><b>Q.</b> ntop doesn't compile.</p>
<p><b>A.</b> Sure, it does - for me :-)</p>
<br>
<p><b>Q.</b> Right smarty-pants...</p>
<p><b>A.</b> First, check if you're using a supported OS.</p>
<p> The long and short of it is that ntop works under Linux, Mac OS X and
FreeBSD.
</p>
<p> Luca distributes a Win32 version through http://shop.ntop.org but charges a
convenience fee. Or you can fire up Microsoft's Visual C++ or Visual C++ .Net
and compile the Win32 version that way.
</p>
<p> It should work under MinGW - see the BUILD file in docs.
</p>
<p> Anything else, you are in untested waters. Some cases we know there are
problems, others we just haven't tested.
</p>
<br>
<p><b>Q.</b> Ok, it's a supported environment and it still won't compile.</p>
<p><b>A.</b> Did you run ./configure? And did it complete successfully?</p>
<p> Usually 'compile' problems for supported platforms are a missing
(critical) library or header file, but the user ignored (didn't see)
the error/warning message and tried running make anyway.
</p>
<p> ./configure checks a lot of things. When it's looking for
headers and libraries, ntop will report KEY information and PROBLEMS
in large, set-off, lines:
</p>
<pre>
*******************************************************************
*
* NOTE: Building ntop for a supported platform
* This means we expect ntop to work without major issues
*
* 'i686-pc-linux-gnu'
*
* Please keep the ntop-dev mailing list updated with any
* successes you have or problems you encounter...
*
* Support for this platform was most recently verified for
*
* RedHat7.2 w/ updates ntop 2.1.51 on 2002-10-21
* Suse i686, 2.4.18-4GB-SMP ntop 2.1.51 on 2002-10-24
*
*******************************************************************
</pre>
<p> READ THESE BOXES. Even if you don't read the rest of the output, read
the boxes. ntop can work around a lot of problems (missing libraries)
by disabling features that need them. If, for example, you don't have
zlib, ntop will compile a version that doesn't output compressed html
pages. If you don't read the boxes, you will never know.
</p>
<p> READ THE MESSAGE BOXES!
</p>
<pre>
*******************************************************************
* *
* NOTICE: I know you're used to ignoring output from ./configure *
* *
* ntop has a lot of complexity and interdependences. *
* *
* Please, please AT LEAST read the stuff in these *
* boxes! *
* *
*>>> The ACTION taken is shown prefixed '>>>' *
* *
* If the ACTION is unacceptable, *
*??? The REMEDIATION plan is shown prefixed with '???' *
* *
*******************************************************************
</pre>
<p> The box will tell you what's wrong, what ntop did and often how to fix it
if you don't like ntop's fix.
</p>
<p> READ THE MESSAGE BOXES!
</p>
<p> Hint: It may sometimes be that you're missing the header files (often those
are in a -devel rpm if you're running RedHat)
</p>
<p> If you see a message box and don't understand why ("I'm sure that
header file is present"), then look at a file called config.log. Search
for the specific header or library reported in the message box and you will
see the detailed compiler/linker error messages.
</p>
<p> For example, ./configure reports:
</p>
<pre>
checking for linux/if_pppox.h... no
</pre>
<p> The first thing to so is check if it's on your system:
</p>
<pre>
$ locate linux/if_pppox.h
/usr/include/linux/if_pppox.h
</pre>
<p> (If you don't have locate, this works too:
</p>
<pre>
$ find / -type f -name "ethertype.h"
)
</pre>
<p> Open up config.log and look for if_pppox.h:
</p>
<pre>
configure:13086: checking for linux/if_pppox.h
configure:13103: gcc -c -g -O2 -Wshadow -Wpointer-arith
-Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fPIC
-DLINUX conftest.c >&5
configure:13158: parse error before '/' token
In file included from configure:13160:
/usr/include/linux/if_pppox.h:38: `ETH_ALEN' undeclared here (not in a
function)
/usr/include/linux/if_pppox.h:39: `IFNAMSIZ' undeclared here (not in a
function)
/usr/include/linux/if_pppox.h:40: confused by earlier errors, bailing out
configure:13106: $? = 1
configure: failed program was:
| #line 13091 "configure"
| /* confdefs.h. */
|
| #define PACKAGE_NAME "ntop"
| #define PACKAGE_TARNAME "ntop"
| #define PACKAGE_VERSION "2.2.91"
| #define PACKAGE_STRING "ntop 2.2.91"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE "ntop"
| #define VERSION "2.2.91"
| #define STDC_HEADERS 1
...
| #define HAVE_NETINET_UDP_H 1
| /* end confdefs.h. */
| net/if.h netinet/if_ether.h
|
| #include <linux/if_pppox.h>
configure:13123: result: no
</pre>
<p> You see the actual test program, the actual compile line and the error
messages.
</p>
<p> Before reporting it to us, chase down where those missing items are declared:
</p>
<pre>
$ grep -R 'ETH_ALEN' /usr/include/* | grep '#define'
/usr/include/linux/if_ether.h:#define ETH_ALEN 6
/usr/include/net/ethernet.h:#define ETHER_ADDR_LEN ETH_ALEN
</pre>
<p> And post that information with your error report. The reason is that these
field definitions are often placed in very different places in different
OSes and even in different distributions.
</p>
<p> FWIW, if you look in the older configure.in:
</p>
<pre>
AC_CHECK_HEADERS([linux/if_pppox.h], [], [], [net/if.h
netinet/if_ether.h])
</pre>
<p> should have been
</p>
<pre>
AC_CHECK_HEADERS([linux/if_pppox.h], [], [], [#include <net/if.h>
#include <netinet/if_ether.h>])
</pre>
<p> because the macro doesn't do the #include automatically.
</p>
<br>
<p><b>Q.</b> Nope, it's not ./configure...</p>
<p><b>A.</b> If it's not the configuration, then it's usually a problem with your specific system, either:
</p>
<pre>
- A new release of a supported OS.
- An uncommon option/configuration of a supported OS.
</pre>
<p> In other words, something is different from what we've seen or expected.
</p>
<p> Review the output from make. The error message will usually give you a
Somewhat cryptic description of what's wrong and where. Look for messages
about missing files. Post as much information as you can - do locates for
the missing files, etc. The more you give us the less we will have to ask
you to provide.
</p>
<p> Remember, we can't see your box - all that the people on the list see is the
information you give in your message.
</p>
<br>
<p><b>Q.</b> Compile dies because it's missing depcomp</p>
<p><b>A.</b> automake/autoconf issue. The problem should have been fixed. If not, just Copy the missing file (or make a symbolic link) into the ntop source
directory.
</p>
<p> It's in /usr/share/automake on my Linux boxes. Another user reports it is in
/usr/local/share/automake in sun8.
</p>
<p> If you have automake installed, this will do it automatically:
</p>
<pre>
$ automake --add-missing --gnu -c
</pre>
<br>
<p><b>Q.</b> Make fails with a message about being unable to create a .deps file.</p>
<p><b>A.</b> Check the permissions on the (hidden) .deps (and .libs) directories - if root owns them your non-root userid may not be able to create files in there.
</p>
<br>
<p><b>Q.</b> Make fails with a message like this:</p>
<pre>
/bin/ld: Warning: size of symbol `pcap_open_dead' changed from 100 to 67
in pcap.o
collect2: ld returned 1 exit status
make[2]: *** [libntop.la] Error 1
make[2]: Leaving directory `/linuxadmin/ntop/ntop2.2.3/ntop-2.2.3'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/linuxadmin/ntop/ntop2.2.3/ntop-2.2.3'
make: *** [all] Error 2
</pre>
<p><b>A.</b> Ah yes, size of symbol...changed. It means you have a conflict between the version of the shared library (be it libpcap, libgd, whatever) that
was used to compile ntop with the version that was used to link ntop.
</p>
<br>
<p><b>Q.</b> 'splain please...</p>
<p><b>A.</b> If you break down a typical link line:</p>
<pre>
gcc -shared address.lo ... ntop_darwin.lo
-L/usr/local/include
-L/usr/local/lib
-L/linuxadmin/ntop/ntop2.2.3/ntop-2.2.3/myrrd
-lpthread -lresolv -lnsl -lz -lc -lssl
-lcrypto -lgd -lpng -lpcap /usr/lib/libgdbm.so
-lmyrrd
-Wl,-soname -Wl,libntop-2.2.3.so
-o .libs/libntop-2.2.3.so
</pre>
<p> You see the mix of -L and -l parameters. The -L parameters ADD
additional places to look for the shared libraries, which are in
addition to the 'standard locations' for the system. The -l
parameters tell which libraries to include.
</p>
<p> Read the man pages (man ld, man ld.so, etc.)
</p>
<p> The 'standard locations' are very system dependent, but usually
include /usr/lib and /lib. PLUS whatever is (under Linux) in the
ld.so.conf file, for example
</p>
<pre>
$ cat /etc/ld.so.conf
/usr/kerberos/lib
/usr/X11R6/lib
/usr/lib/qt-3.0.5/lib
/usr/local/lib
</pre>
<p> So, on this system, to resolve a library, ld looks in the -L values:
</p>
<pre>
1. /usr/local/include
2. /usr/local/lib
3. /linuxadmin/ntop/ntop2.2.3/ntop-2.2.3/myrrd
</pre>
<pre>
And then the 'standard' places:
</pre>
<pre>
4. /usr/kerberos/lib
5. /usr/X11R6/lib
6. /usr/lib/qt-3.0.5/lib
7. /usr/local/lib
8. /lib
9. /usr/lib
</pre>
<p> Similarly, if you break apart the gcc COMPILE line and scrap the dups,
you'll have a different set of places where gcc looks for the .h files.
For those, it's the -I parameters plus whatever is 'standard' on your
system, which is dependent on the specific gcc port:
</p>
<p> /bin/sh ./libtool --mode=compile gcc -DHAVE_CONFIG_H -DLINUX
</p>
<pre>
-I. -I/linuxadmin/ntop/ntop2.2.3/ntop-2.2.3/myrrd
-I/usr/local/include
-g -O2 -fPIC -g -O2 -c
-Wshadow ... -Wnested-externs
-o ntop_darwin.lo
</pre>
<p> Again, read the gcc man page.
</p>
<p> A big problem is that - unlike .so files, it's not real clear what
directories ARE searched for .h files, only that there is a set.
</p>
<p> With me so far? Go back to the message... what it means is that:
</p>
<pre>
* From one set of locations, at compile time, the size of
the parameter list for pcap_open_dead was 100 bytes.
* From the other set of locations, at link (ld) time, the
library expects the parameter list to be of size 67.
</pre>
<p> Danger, Will Robinson...
</p>
<p> The most likely cause of this problem is when you tell ntop to look at
one location to resolve either the .h or .so and it finds the other,
'automatically' in a 'standard' location, but the two are actually from
incompatible versions.
</p>
<p> Say you have libpcap 0.6.2 installed by the os in /usr/lib and
/usr/include, but you also install libpcap 0.7.2 in /usr/local/lib and
/usr/local/include.
</p>
<pre>
$ locate pcap.h
/usr/include/pcap.h
/usr/local/include/pcap.h
</pre>
<p> and
</p>
<pre>
$ locate libpcap.so
/usr/lib/libpcap.so.0
/usr/lib/libpcap.so
/usr/lib/libpcap.so.0.6.2
/usr/lib/libpcap.so.0.6
/usr/local/lib/libpcap.so.0
/usr/local/lib/libpcap.so
/usr/local/lib/libpcap.so.0.7.2
/usr/local/lib/libpcap.so.0.7
</pre>
<p> If all you give ./configure is --with-pcap-header=/usr/local/lib
</p>
<pre>
* At compile time, it finds the pcap.h in /usr/local/lib (0.7.2)
* At link time, it finds the libpcap.so in the 'default',
/usr/lib/libpcap.so which is actually libpcap.so.0.6.2
</pre>
<p> ntop did EXACTLY what you told it to do. The fact that it makes no
sense is a problem, so you get the error message.
</p>
<br>
<p><b>Q.</b> So the real solution is?</p>
<p><b>A.</b> Give ntop pointers to consistent sets of header and library files, and maybe don't have multiple versions of the same library installed at once.
</p>
<br>
<p><b>Q.</b> I'm done compiling and it works/doesn't work, what do I do?</p>
<p><b>A.</b> make install (You'll typically need to be root for this to work)</p>
<br>
<p><b>Q.</b> I'm seeing a lot of "changing search order for system directory" messages?</p>
<p><b>A.</b> It's not a problem, just confusing. This warning, which appears if you redefine the system include directory, causes lots of confusion. Supposedly,
according to this http://gcc.gnu.org/ml/gcc-bugs/2002-10/msg01080.html,
it wasn't fixed in gcc 3.2.0, but should be fixed in gcc 3.2.1.
</p>
<p> According to this: http://gcc.gnu.org/onlinedocs/cpp/Invocation.html,
it's truly harmless on systems which already have /usr/local/include as
a standard system library:
</p>
<pre>
-I dir
Add the directory dir to the list of directories to be searched for
header files. See Search Path. Directories named by -I are searched
before the standard system include directories. If the directory dir
is a standard system include directory, the option is ignored to ensure
that the default search order for system directories and the special
treatment of system headers are not defeated (see System Headers) .
</pre>
<h2>Other ./configure features</h2>
<br>
<p><b>Q.</b> How do I update the Vendor Table (MAC address prefixes)?</p>
<p><b>A.</b> ntop has (in Makefile), a rule to automatically download the latest vendor information table from the IEEE, the oui.txt file ntop reads.
</p>
<p> If you are seeing unknown MAC address prefixes (the 1st three units), try
the full IEEE table. To rebuild it:
</p>
<pre>
# make dnvt
</pre>
<p> and then copy the new oui.txt over the one installed by ntop originally.
</p>
<p> Also note that the table changes over time - there are almost 600
Modifications and/or new assignments between the version shipped with
ntop 2.0 and the version on the IEEE site in February 2002.
</p>
<br>
<p><b>Q.</b> How do I update the passive ethernet fingerprint database?</p>
<p><b>A.</b> ntop has (in Makefile), a rule to automatically download the latest ettercap file from SourceForge:
</p>
<pre>
# make dnetter
</pre>
<p> It will also compress the file and tell you how big the old and new files
were.
</p>
<br>
<p><b>Q.</b> How do I update the IP to Country Code table?</p>
<p><b>A.</b> Again, ntop has (in Makefile), a rule to automatically download the latest data and build the file.
</p>
<pre>
# make p2c
</pre>
<p> Note that this is actually a fairly complex script (utils/p2c) and is
dependent upon data posted to supposedly well known locations by the various
internet number authorities (APNIC, RIPE, etc.)
</p>
<p> It's a LOT of data to download so don't do this on a site with a slow
link to the internet. Also, read the output carefully and DO NOT apply a
file if there are messages you don't understand.
</p>
<br>
<p><b>Q.</b> But the IP -> CC data is wrong.</p>
<p><b>A.</b> Yeah. Most people don't care :-(... it's enough to see various pretty flags.
</p>
<p> Sadly, the registries often post files with errors in them. Some Tier
1 ISPs post their own data to elaborate on the registry data. Most ISPs
don't post data. Some entries in the files make 'logical' sense, but not
physical sense.
</p>
<p> If you find another set of data, let us know - the shell script is pretty
easy to follow to add another data source.
</p>
<p> The user who used to care about this (Mr. Anon E. Mouse) used to send me
a file of corrections to apply to the file we posted with ntop.
</p>
<p> If such a file exists, it would be posted @ SourceForge in the user
contributed area.
</p>
<br>
<p><b>Q.</b> I have installed ntop for OSX but I cannot start it as I have installed some libraries using fink and ntop cannot find them.
</p>
<p><b>A.</b> The easiest thing to do is to do: ln -s /sw/lib/myfinklibrary /usr/local/lib Courtesy of Matthew Scholz <matts@discovery.org>
</p>
<h2>Running Startup</h2>
<br>
<p><b>Q.</b> ntop won't start - I get this message:</p>
<pre>
** FATAL ERROR** ... open of /var/ntop/addressQueue.db failed:
File open error
</pre>
<p><b>A.</b> It's either permissions (the ntop -u userid doesn't have read/write access to that file - common if you're upgrading from 2.2 to 3.0).
</p>
<p> The other cause is that there's still an instance of ntop running. Make
sure you shutdown ntop before starting it.
</p>
<br>
<p><b>Q.</b> What is the function of the 'ntop' script in the build directory - should I call it or /usr/local/bin/ntop ?
</p>
<p><b>A.</b> (from the comments in the script):</p>
<pre>
# ntop - temporary wrapper script for .libs/ntop
# Generated by ltmain.sh - GNU libtool 1.4 (1.920 2001/04/24 23:26:18)
#
# The ntop program cannot be directly executed until all the libtool
# libraries that it depends on are installed.
#
# This wrapper script should never be moved out of the build directory.
# If it is, it will not operate correctly.
</pre>
<p> It allows you to run ntop out of the build directory before doing a "make
install" by doing all the necessary linkage magic - such as forcing a relink
if it didn't succeed originally - to the files in .libs.
</p>
<p> Think of it as simulating make install, but not moving stuff to /usr/local
or wherever.
</p>
<p> Don't use it - it just causes problems...
</p>
<br>
<p><b>Q.</b> Which libraries do I need?</p>
<p><b>A.</b> To run ntop: glibc, gdbm, libpcap</p>
<pre>
For https://, add openssl.
For other tools and compile options, add the appropriate libraries.
</pre>
<br>
<p><b>Q.</b> ntop seems to run, but the web server isn't up.</p>
<p><b>A.</b> Set the password - see docs/1STRUN.TXT</p>
<br>
<p><b>Q.</b> How do you reset Admin password if we lost it?</p>
<p><b>A.</b> Delete ntop_pw.db and follow the procedure in docs/1STRUN.txt</p>
<br>
<p><b>Q.</b> I'm being prompted to set a password, what do I enter.</p>
<p><b>A.</b> Anything you want, of 5 or more characters. If ntop can't find the value in it's database, it will prompt you to set on. If this happens every
time you start ntop, check the permissions on the ntop_pw.db file.
</p>
<br>
<p><b>Q.</b> Characters after the 8th are being ignored in my password.</p>
<p><b>A.</b> Probably. ntop uses the standard crypt() function provided by the OS.</p>
<p> While crypt() is required part of the single unix specification, the
details are implementation dependent. Whatever the limitations of crypt()
are, that what ntop's limits are.
</p>
<p> Unfortunately, there's no way to tell programatically what these limits are,
you have to refer to the man page for crypt(3).
</p>
<p> There is a "GNU EXTENSION" to crypt() which implies that changing the 'salt'
ntop uses would allow longer passwords. That's set via CONST_CRYPT_SALT in
globals-defines.h, but AFAIK this hasn't been tested.
</p>
<br>
<p><b>Q.</b> How does the @filename option work e.g. /usr/bin/ntop ... @filename ...</p>
<p><b>A.</b> The text of 'filename', is copied - ignoring line breaks and comments (anything following a #) - into the command line.
</p>
<p> ntop behaves as if all of the text had simply been typed directly
on the command line. Multiple @s are permitted in the command
line, nesting is not. @s in the file will cause an error.
</p>
<p> Both are displayed on the info.html report, the "Started as"
shows the actual command line ntop was given and the
"Resolved to" shows what ntop processed.
</p>
<p> Started as /usr/bin/ntop -i eth0,eth1 @/root/ntop_parms -d -L
</p>
<p> with /root/ntop_parms containing:
</p>
<pre>
-p /usr/share/ntop/protocol.list
-P /usr/share/ntop
-w 192.168.42.38:3000
# -W 192.168.42.38:3001
-u ntop
--trace-level 3
-m 12.239.0.0/16,10.113.0.0/16
-E
-K
</pre>
<p> becomes:
</p>
<p> Resolved to /usr/bin/ntop -i eth0,eth1 -p /usr/share/ntop/protocol.list
</p>
<pre>
-P /usr/share/ntop -w 192.168.42.38 -u ntop --trace-level 3
-m 12.239.0.0/16,10.113.0.0/16 -E -K -d -L
</pre>
<p> Remember, most ntop options are "sticky", that is they just set an
internal flag. Invoking them multiple times doesn't change ntop's
behavior. However, options that set a value, such as --trace-level,
will use the LAST value given: --trace-level 2 --trace-level 3 will
run as --trace-level 3.
</p>
<p> It is recommended that you use FULL pathnames for @filename, since
ntop may have different effective directories when run in different
ways. However, you may wish to use relative pathnames to take
advantage of the different effective directories (say cron vs.
command line). Just know where you're starting.
</p>
<br>
<p><b>Q.</b> ntop seems to run but I don't see any traffic.</p>
<p><b>A.</b> Make sure you aren't running against the loopback (127.0.0.1) interface. lo shouldn't see much traffic, only that originating on the host destined
for it (e.g. ping 127.0.0.1).
</p>
<br>
<p><b>Q.</b> ntop is unable to open its database file. Specifically: I have following messages while running ntop
</p>
<pre>
wait please: ntop is coming up...
24/Jul/2003 15:15:23 Initializing IP services...
<snip />
24/Jul/2003 15:15:23 Initializing GDBM...
24/Jul/2003 15:15:23 ***FATAL_ERROR*** open of ...name... failed: can't be writer
24/Jul/2003 15:15:23 Possible solution: please use '-P <directory>'
</pre>
<p><b>A.</b> Multiple possible choices...</p>
<p> * Another ntop already running
</p>
<p> (Most common) You forgot the -P parameter, and ntop is using a default value that
doesn't exist. Just as the message says, use the -P parameter to point ntop at
the directory you want it to use.
</p>
<p> * Some sort of file system problem (non-existent directory, permissions, etc.)
</p>
<p> 1. The directory shown doesn't exist. Create it.
</p>
<p> 2. You many not have read/write rights in that directory.
This can occur if you run ntop both as root and (as recommended) as a non-root user.
</p>
<p> 3. Another instance of ntop may already be running, so it has the file open and locked.
</p>
<br>
<p><b>Q.</b> What's inside the .db files and what's their format?</p>
<p><b>A.</b> The files are stored in GDBM format. You can dump their content using tools like this: http://tboudet.free.fr/dumpgdbm/. In principle you should not be
interested in the file content as they are temporary caches and contain the
configuration as well as the MD5 hash of the web passwords.
</p>
<p> I posted a trivial dumpgdbm.c to gmane - search for it.
</p>
<br>
<p><b>Q.</b> ntop starts up with this: WARNING: Discarded network 172.20.0.0/16: this is the local network.
</p>
<p><b>A.</b> No worries. The message means exactly what it says - it's a warning that you gave the local network as one of the parameter(s) to -m. Since the
local networks are always local, ntop doesn't need to make them pseudo-local.
</p>
<br>
<p><b>Q.</b> What are ntop's options?</p>
<p><b>A.</b> There are a couple of options that appear only if they're not compiled in, and a few that depend on various external libraries, e.g. openSSL.
</p>
<p> The best way to see what is actually available is to run ntop with the -h or
--help options and see. Also read man ntop.
</p>
<br>
<p><b>Q.</b> -4 and -6?</p>
<p><b>A.</b> The default for the ntop web server is to connect to any address and any family of addresses, so if the NIC has both IPv4 and IPv6 addresses it should respond
to both. Use these to restrict the web server.
</p>
<br>
<p><b>Q.</b> --trace-level?</p>
<p><b>A.</b> The settings 0..4 control the amount of information logged or displayed. DETAIL (5) adds a [MSGIDnnnn] field and (VERYNOISY) 6 or greater adds the
file:line where the message originated.
</p>
<p> -t 5 can be useful with a log watch type package, -t 6 is mostly for debugging.
</p>
<p> -t 5:
</p>
<pre>
[MSGID8757584] OSFP: scanFingerprintLoop() checked 1, resolved 1
</pre>
<p> -t 6:
</p>
<pre>
[MSGID8757584] [ntop:698] OSFP: scanFingerprintLoop() checked 1, resolved 1
</pre>
<p> With 3.2 we've added VERYNOISY and (7) BEYONDNOISY ... they do pretty much what they
say. Have LOTS of log space available.
</p>
<br>
<p><b>Q.</b> ntop starts up find and then seems to die.</p>
<p><b>A.</b> Are the ntop threads still there? Use ps to check, for example: # ps -C ntop -m -o "uid,pid,ppid,stat,time,command"
</p>
<pre>
UID PID PPID STAT TIME COMMAND
501 18327 1 S 00:00:00 /usr/bin/ntop -i eth1,eth2 @/etc/ntop.conf...
501 18330 18327 S 00:00:00 /usr/bin/ntop -i eth1,eth2 @/etc/ntop.conf...
501 18331 18330 S 00:00:05 /usr/bin/ntop -i eth1,eth2 @/etc/ntop.conf...
501 18332 18330 S 00:00:45 /usr/bin/ntop -i eth1,eth2 @/etc/ntop.conf...
501 18333 18330 S 00:00:00 /usr/bin/ntop -i eth1,eth2 @/etc/ntop.conf...
501 18334 18330 S 00:00:06 /usr/bin/ntop -i eth1,eth2 @/etc/ntop.conf...
501 18335 18330 S 00:00:00 /usr/bin/ntop -i eth1,eth2 @/etc/ntop.conf...
501 18336 18330 R 00:00:32 /usr/bin/ntop -i eth1,eth2 @/etc/ntop.conf...
501 18337 18330 S 00:00:41 /usr/bin/ntop -i eth1,eth2 @/etc/ntop.conf...
</pre>
<p> The 'PID' numbers match the THREADMGMT: numbers in the log:
</p>
<pre>
ntop[18326]: INIT: Parent process is exiting (this is normal)
^^^^^ is the thread that issued the message
</pre>
<pre>
ntop[18327]: INIT: Bye bye: I'm becoming a daemon...
(18327 is the 'master' thread created as ntop becomes a daemon)
</pre>
<pre>
ntop[18327]: THREADMGMT[t105061296]: SFP: Started thread for fingerprinting
A message is issued for each thread started.
t^^^^^^^^^ is the 'internal' thread #. Ignore it
ntop[18331]: THREADMGMT[t105061296]: SFP: Fingerprint scan thread starting [18331]
p^^^^^
is the child pid. Each one issues a message as it starts up
</pre>
<p> So:
</p>
<pre>
UID PID PPID STAT TIME is
501 18327 1 S 00:00:00 Master
501 18330 18327 S 00:00:00 (internal used by POSIX)
501 18331 18330 S 00:00:05 Packet processor
501 18332 18330 S 00:00:45 Idle Host Scan
501 18333 18330 S 00:00:00 Address Resolution
501 18334 18330 S 00:00:06 rrd
501 18335 18330 S 00:00:00 Web Server
501 18336 18330 R 00:00:32 eth1
501 18337 18330 S 00:00:41 eth2
</pre>
<p> If you connect to the running ntop via gdb, you can see this:
</p>
<p> $ gdb /usr/bin/ntop 18327
(gdb) info threads
</p>
<pre>
^^^^^^^^^^^^ Shows all the threads and their current state
</pre>
<pre>
9 Thread 114696 (LWP 18337) 0x40255c68 in recvfrom () from
/lib/i686/libpthread.so.0
8 Thread 98311 (LWP 18336) 0x40255c68 in recvfrom () from
/lib/i686/libpthread.so.0
7 Thread 81926 (LWP 18335) 0x420dcc31 in select () from
/lib/i686/libc.so.6
6 Thread 65541 (LWP 18334) 0x420b0226 in nanosleep () from
/lib/i686/libc.so.6
5 Thread 49156 (LWP 18333) 0x40252a35 in __pthread_sigsuspend ()
from /lib/i686/libpthread.so.0
4 Thread 32771 (LWP 18332) 0x420b0226 in nanosleep () from
/lib/i686/libc.so.6
3 Thread 16386 (LWP 18331) 0x40252a35 in __pthread_sigsuspend ()
from /lib/i686/libpthread.so.0
2 Thread 32769 (LWP 18330) 0x420db1a7 in poll () from
/lib/i686/libc.so.6
1 Thread 16384 (LWP 18327) 0x420b0226 in nanosleep () from
/lib/i686/libc.so.6
</pre>
<p> (gdb) thread 2
</p>
<pre>
^^^^^^^^ switch to thread 2 and see it's state
</pre>
<p> [Switching to thread 2 (Thread 32769 (LWP 18330))]#0 0x420db1a7 in
</p>
<pre>
poll () from /lib/i686/libc.so.6
</pre>
<p> (gdb) info stack
</p>
<pre>
^^^^^^^^^^ check the call stack
</pre>
<p> #0 0x420db1a7 in poll () from /lib/i686/libc.so.6
#1 0x4024f9de in __pthread_manager () from /lib/i686/libpthread.so.0
</p>
<pre>
^^^^^^^^^^^^^^^^^ running __pthread_manager
</pre>
<br>
<p><b>Q.</b> All the threads seem to be running ok.</p>
<p><b>A.</b> Check if there's one that looks like this:</p>
<pre>
4 Thread 32771 (LWP 27295) 0x420cd207 in sched_yield () from
/lib/i686/libc.so.6
</pre>
<p> Let ntop run a few more seconds (cont command), then check again.
</p>
<p> If it's frozen in the sched_yield, you're probably tripping a deadlock
situation that we've seen but don't understand - There's a lot of
stuff on the 'net, including what seems to be the same problem with
other resource intensive tools but no clear answers.
</p>
<p> This happens most often on RedHat Linux 8.0 (9 uses a different
threading library and the issue hasn't been reported there).
</p>
<p> Regardless, if you see the deadlock or just have a hung ntop, there is a
run time option to try: --disable-schedyield. This option disables the
calls at a slight penalty to ntop's interactivness. If you're experiencing
the deadlocks, try it.
</p>
<p> And, especially if you're running something other than RedHat 8, please
let the ntop-dev list know about it.
</p>
<br>
<p><b>Q.</b> Can I set the admin password from a script?</p>
<p><b>A.</b> Yes, you can call ntop with the option:</p>
<pre>
ntop --set-admin-password=password
</pre>
<br>
<p><b>Q.</b> What's this warning about ownership?</p>
<p><b>A.</b> The first time you run make install and ntop creates a new directory for ntop's files, there's a problem. So you'll
see this warning box:
</p>
<pre>
************************************************************
************************************************************
</pre>
<pre>
WARNING: This install created a directory for the ntop
files and databases:
</pre>
<pre>
some directory...
</pre>
<pre>
This directory MUST be owned by the user
which you are going to use to run ntop.
</pre>
<pre>
The command you must issue is something like:
</pre>
<pre>
chown -R ntop.ntop <directory>
or chown -R ntop:users <directory>
</pre>
<pre>
man chown to check the syntax for YOUR system
</pre>
<pre>
************************************************************
************************************************************
</pre>
<p> Since root created the directory, root is the owner. And since we don't
know - yet - what user ntop is going to be run as, we can't issue the
chown (CHange OWNership) command for you.
</p>
<br>
<p><b>Q.</b> And if I don't do this?</p>
<p><b>A.</b> ntop won't run. Typically you get a message about a bad -P file or endless prompts for the admin password.
</p>
<br>
<p><b>Q.</b> I can't merge interfaces (-M option)?</p>
<p><b>A.</b> Check your plugins and see if either netFlow or sFlow is active. Regardless of whether you're using them, if they're active, they
(silently) force the -M switch on.
</p>
<p> If you have used the web configuration to set this, you may be
unintentionally overriding your command line.
</p>
<p> With v3.2 there are log messages telling you what sets interface
merge.
</p>
<pre>
NOTE: Interface merge disabled by default
NOTE: Interface merge enabled by default
NOTE: Interface merge disabled from prefs file
NOTE: Interface merge enabled from prefs file
NOTE: Interface merge disabled due to command line switch
</pre>
<br>
<p><b>Q.</b> Explain -u.</p>
<p><b>A.</b> -u root means that you are running ntop as root. It means you don't drop root's superuser privledges, so pretty much you can read/write any file.
It's not a good idea. While we're not aware of any security problems with
ntop, programs that run as root are targets.
</p>
<p> -u ntop (or -u whatever) means you run as a normal user and can be assigned
only the privledges necessary to run ntop. It also means you can only read/
write files as ntop. So less is exposed.
</p>
<p> For even better security, the -u userid should not have a valid shell, so
people can't use it to login.
</p>
<br>
<p><b>Q.</b> What are the options that reduce ntop's workload?</p>
<p><b>A.</b> These options turn off certain processing (and thus limit ntop's functionality), and may be appropriate for high volume installations.
</p>
<p> -b | --disable-decoders
</p>
<pre>
This flag disables protocol decoders. Use it for better performance
or if you feel ntop has problems handling these protocols in your
environment.
</pre>
<pre>
This switch disables code in a number of places throughout ntop, code
which analyzes specific protocols, but can place additional load on the
host. This switch could be used to run ntop on low-end CPUs or where
ntop is acting as a collector (netFlow or sFlow) and the GUI is not
required.
</pre>
<pre>
Disabled is the analysis of:
</pre>
<pre>
DNS Sniffing - where ntop captures DNS information from other hosts'
requests to reduce the # of DNS requests ntop must -
itself - make.
</pre>
<pre>
NetBIOS \
NetWare \
AppleTalk -- resource intensive protocol analysis of less
bootp/dhcp / common protocols.
OSI /
</pre>
<pre>
http (80) - Request success/failure counting on port 80 and other
analysis, including "Virtual Host".
</pre>
<pre>
ftp passive session tracking.
</pre>
<pre>
"Wrong Port" monitoring for: http, ftp and smtp (used with the
-q | --create-suspicious-packets option to dump "suspicious"
packets to an analysis file) With this option, ntop checks
the payload for each new connection, looking for text usually
present in http, ftp or smtp requests. If these are not on the
"normal" ports (http's 80, ntop's 3000 or squid's 3128, ftp's
21 or smtp's 25) (or there is a non-ftp or smtp request on the
standard ports), the packet is logged.
</pre>
<p> -g | --track-local-hosts
</p>
<pre>
Use this flag to tell ntop that you care only about local hosts (use
-m | -- local-subnets to specify local nets). This flag is useful when
ntop sees many hosts (e.g. border gateway) but only the local ones need
to be tracked.
</pre>
<pre>
This switch disables code in a number of places throughout ntop, code
which allows ntop to track "foreign" hosts (that is ones not local
according to the IP address(es) of ntop's interfaces or set pseudo-local
by -m | -- local-subnets).
</pre>
<pre>
Basically, ntop doesn't bother to do DNS resolution on these addresses
and, for purposes of various counts, uses the "other" bucket instead of
creating a unique hash table bucket for the specific host.
</pre>
<pre>
This switch could be used to run ntop on low-end CPUs or where ntop is
acting as a collector (netFlow or sFlow) and the GUI is not required.
</pre>
<p> -o | --no-mac
</p>
<pre>
Specifies that ntop should not trust MAC addresses but just IP addresses.
This option is useful whenever ntop is started on an interface where MAC
(Media Access Controller - the low-level Ethernet address) addresses can
not really be trusted (e.g. port/VLAN mirror in Switched Ethernet
environments).
</pre>
<pre>
Certain processing is performed differently:
</pre>
<pre>
Hash search is via IP not MAC
</pre>
<pre>
Certain capabilities are disabled:
</pre>
<pre>
Analysis of bootp/dhcp requests
localRoutersList.html report
Wrong net mask log message and flag
Analysis of non-tcp/udp protocols like NetWare and Spanning Tree
Router listing on Host Detailed report.
Traffic Matrix report
</pre>
<pre>
(Note that this list is subject to change as we learn more about protocols
that do/do not depend on the MAC address)
</pre>
<pre>
See also -z | --disable-sessions
</pre>
<p> -z | --disable-sessions
</p>
<pre>
This flag disables tcp session tracking. Use it for better performance or
when you don't really need the tracking of sessions.
</pre>
<pre>
Also, in situations where the MAC addresses cannot be trusted, ntop may
- or may not - be able to accurately track tcp sessions. There is no easy
way to tell, so this switch puts control back into the users' hands.
</pre>
<pre>
In versions after 2.0 up to & including 2.1.2, the -j |
--border-sniffer-mode flag (predecessor of -o | --no-mac) always turned
this off. Many users wanted to try turning session tracking back on, and
did via code patches with mixed results.
</pre>
<pre>
Suggested usage: If you enable -o | --no-mac, try running ntop with
sessions enabled. If the data looks reasonable, congratulations - your
network allows session tracking. If the data does not look reasonable,
then you will also need to disable session tracking with this switch.
</pre>
<br>
<p><b>Q.</b> -s | --no-promiscuous doesn't work</p>
<p><b>A.</b> It should work - it's passed to pcap_open_live.</p>
<p> But, whether the flag is supported by the OS and whether it is actually
respected by the interface depends on libpcap. If it fails, you'll see
a message and ntop will refuse to startup.
</p>
<p> Understand that if it actually does work, it means that ntop sees a lot
less comprehensive view of the traffic.
</p>
<p> But from the ntop web server, you won't see anything different.
</p>
<p> You can check (*nix) by executing ifconfig on the interface.
</p>
<p> Note that the parameter specifies if the interface is to be put into
promiscuous mode because of ntop.
</p>
<p> Even if this parameter is false, the interface could well be in promiscuous
mode for some other reason. And in some situations, the interface may be
forced by the low level driver into promiscuous mode, without reporting
this to the kernel!
</p>
<br>
<p><b>Q.</b> How does -m | --local-subnets work?</p>
<p><b>A.</b> This flag allows users to specify the subnets whose traffic is considered local (called "pseudoLocal" internally).
</p>
<p> The format is
</p>
<pre>
<network address>/<# subnet mask bits>[,<network address>/<# subnet
mask bits>
</pre>
<p> For instance "131.114.21.0/24,10.0.0.0/255.0.0.0".
</p>
<br>
<p><b>Q.</b> (followup) but what does it MEAN?</p>
<p><b>A.</b> Surprisingly, it means EXACTLY what it says. Treat traffic on the listed subnet(s) as local.
</p>
<p> -m relates to the traffic you see on the wire at the TCP/IP level.
-m tells ntop something it can't determine by itself. And that is to
treat a range of addresses EXACTLY like it was local.
</p>
<p> For example, on my Cable Modem, I see broadcasts for a number of subnets
that AT&T (now Comcast) has assigned to this area (I don't see the
traffic just the broadcasts).
</p>
<p> If you have VLANs or simply network overlays (two or more networks on the
same wire, but with separate address spaces). etc.
</p>
<p> Those are the cases where you use -m. To tell ntop to treat that traffic
as local.
</p>
<br>
<p><b>Q.</b> Why</p>
<pre>
A ntop differentiates between local traffic and remote traffic. There are
actually four classes (although only three are routinely reported) L->L L->R
R->L and R->R. Some additional processing is done and some additional
reporting is available for L traffic.
</pre>
<br>
<p><b>Q.</b> I'm confused. Explain, please!</p>
<p><b>A.</b> Suppose your IP is 1.2.3.4 with a 255.255.255.0 netmask (a/k/a 1.2.3.4/24)</p>
<p> Under the TCP/IP protocol, traffic with any address 1.2.3.1 -> 1.2.3.254 does
not get routed. It's "local".
</p>
<p> Your buddy is at 1.2.3.9 and the router is 1.2.3.1, so your network looks
like this:
</p>
<p> the +--------+
world-----+ Router +--1.2.3.1--------------------------------------
+dog +--------+ | 1.2.3.4 | 1.2.3.9
</p>
<pre>
+--------+ +--------+
| You | | Buddy |
+--------+ +--------+
</pre>
<p> Say you send a packet to your buddy at 1.2.3.9. You build a packet with
SRC=1.2.3.4 DST=1.2.3.9 and your data and cast it out the wire. (For
purposes of this illustration, ignore the fact the your TCP stack would
recognize the "local" nature of the packet and actually use another, lower
level protocol, called Ethernet to deliver it.)
</p>
<p> The router (1.2.3.1) looks at it, does the math and ignores it - it's local
Your buddy (1.2.3.9) looks at it, says - gee, that's me and reads it
</p>
<p> This is L->L traffic.
</p>
<p> Now you send a packet to ntop.org at 131.114.21.9. Again, SRC=1.2.3.4 and
Now DST=131.114.21.9.
</p>
<p> The router (1.2.3.1) looks at it, does the math and says - oops, I have to
send it out to the world. Your buddy (1.2.3.9) looks at it, says - gee that's
NOT me and ignores it
</p>
<p> This is L->R traffic.
</p>
<p> Now it's perfectly possible to have multiple (physical) networks on the same
physical wire. Say that your ISP chooses to put 1.2.4.1-1.2.4.254
(1.2.4.0/24) on the same wire. (Why would they do this? - maybe it's a big
pipe and only a few users or whatever).
</p>
<p> A packet from 1.2.4.4 -> 1.2.4.9 is seen by
</p>
<p> The router - no, that too is local, ignore it
You (1.2.3.4): (1.2.4.9) - not me - ignore it
Buddy (1.2.3.9) - um... 1.2.4.9 - not me - ignore it
</p>
<p> And that's perfectly legal.
</p>
<p> But what if you are the ISP and you want ntop to see ALL the traffic on that
wire? ntop will figure out from it's own IP address that the 1.2.3.0/24
traffic is local, but it will classify the 1.2.4.0/24 as REMOTE.
</p>
<p> And that is what the --local-subnets switch does. It tells ntop to treat
that 1.2.4.0/24 traffic as local.
</p>
<p> If there isn't any other traffic on the wire, then telling ntop to treat it
as local won't change a thing.
</p>
<p> You can always use a packet sniffer, such as tcpdump to scan the traffic on
the wire and see what's really there...
</p>
<br>
<p><b>Q.</b> And internally?</p>
<p><b>A.</b> ntop is designed as a hybrid packet analyzer, not a pure Ethernet analyzer (layer 2) nor a pure TCP/IP analyzer (layer 3). Most of ntop's displayed
counts are at the TCP/IP level, and that's what confuses people. Internally,
ntop works both at the level of the Ethernet frame and the TCP/IP packet.
</p>
<p> A single MAC address can be associated with multiple TCP/IP addresses. The
MAC address -- unless something is horribly wrong on the network or with the
hardware or somebody is deliberately spoofing it -- is guaranteed to be
unique and refers to a physical host or network interface. For many reports,
ntop displays the information using the MAC address to separate physical
devices. Other data is accumulated and displayed at the TCP/IP (level 3)
layer.
</p>
<p> -m relates to the traffic you see on the wire at the TCP/IP level.
-m tells ntop something it can't determine by itself. And that is to treat
that range of addresses EXACTLY like it was local.
</p>
<p> For example, on my Cable Modem, I see broadcasts for a number of subnets
that AT&T has assigned to this area (I don't see the traffic, but you get
the picture) in an overlay structure (two or more networks on the
same wire, but with separate address spaces).
</p>
<br>
<p><b>Q.</b> What about multicast traffic?</p>
<p><b>A.</b> Multicast traffic uses the 224.0.0.0/4 address range (that is all addresses between 224.0.0.0 and 239.255.255.255 - see RFC 1112). By default then,
all multicast traffic is treated as 'Remote' by ntop.
</p>
<p> Your actual network topology may be such that multicast traffic could
all be local, all be remote or a mixture. You can use the -m |
--local-subnets parameter to force some (or all) multicast groups
to be counted as 'Local' traffic.
</p>
<br>
<p><b>Q.</b> What about VLANs?</p>
<p><b>A.</b> VLAN traffic is also a special case. ntop treats all traffic within your machine's netmask definition as 'Local'. For instance, you may have a /16
network (netmask of 255.255.0.0), and you are using VLANs to distribute
the traffic. In this case ntop will see the a.b.c.d/16 address and classify
all traffic within this /16 network as 'Local'.
</p>
<p> Don't design your network that way.
</p>
<br>
<p><b>Q.</b> But they did!</p>
<p><b>A.</b> This MIGHT work:</p>
<p> Use an un-numbered interface, so that ntop doesn't assign any implicit
'Local' addresses. Then use the -m | --local-subnets parameter to
define what is truly 'Local'. As long as there aren't too many
'Local' networks, this should work. I run something sort of like this
(but using /24s not subdividing a /16) for my development network.
</p>
<br>
<p><b>Q.</b> What are the default protocols ntop monitors?</p>
<p><b>A.</b> (These are the ones ntop monitors if the user does not supply a -p parameter) Check addDefaultProtocols() in ntop.c around line 525.
The current list (December 2004) is
</p>
<pre>
Protocol Ports
-------- -----
</pre>
<pre>
FTP ftp ftp-data
HTTP http www https 3128 /* 3128 is HTTP cache */
DNS name domain
Telnet telnet login
NBios-IP netbios-ns netbios-dgm netbios-ssn
Mail pop-2 pop-3 pop3 kpop smtp imap imap2
DHCP/BOOTP 67-68
SNMP snmp snmp-trap
NNTP nntp
NFS/AFS mount pcnfs bwnfs nfsd nfsd-status 7000-7009
X11 6000-6010
SSH 22
Gnutella 6346 6347 6348
Morpheus 1214
WinMX 6699 7730
DirectConnect
eDonkey 4661-4665
BitTorrent 6881-6999 6969
Messenger 1863 5000 5001 5190-5193
</pre>
<p> Note that the names come from /etc/services (or your system's equivalent).
If you add protocols to /etc/services, you can refer to them by name on the
-p parameter.
</p>
<p> REMEMBER: You must define the list using the format illustrated in the ntop
man page. Don't try to read /etc/services. It will fail.
</p>
<p> The list changes over time as P2P protocols appear and disappear. Check the
cvs and diff ntop.c (around line 550 in void addDefaultProtocols() if you
want the history.
</p>
<br>
<p><b>Q.</b> What about protocol XYZZY?</p>
<p><b>A.</b> The analysis of protocols is very limited and unsophisticated. But, theoretically, if it's there in plain text, we could report on it.
The more work you can do up front in identifying the protocol (e.g. port #s,
header structure, etc.), the easier it would be to add.
</p>
<br>
<p><b>Q.</b> I am using a /16 (/25 or whatever) mask and I get this message:</p>
<pre>
Truncated network size to 1024 hosts (real netmask 255.255.255.0)
</pre>
<p><b>A.</b> Yes. ntop limits each network to 1024 hosts (a /24). If you need more, alter the #define for MAX_SUBNET_HOSTS in globals-defines.h and recompile. Space
has to be reserved for this many hosts for each network, so the limit exists
to keep memory usage from growing to absurd levels on people with "class A"
(/8) interfaces (e.g. 10. or Cable Modems, etc.).
</p>
<br>
<p><b>Q.</b> What's with the version check?</p>
<br>
<p><b>Q.</b> Why is ntop connecting to jake.ntop.org?</p>
<p><b>A.</b> jake.ntop.org is the cannonical name for version.ntop.org, which hosts the xml file used for the version check.
</p>
<p> See the man page, 1st run log messages and/or privacyNotice.html page (Click on the
"this" in this line: "For information on ntop and information privacy, see this page."
on the 1st page ntop presents).
</p>
<h2>Running Ongoing</h2>
<br>
<p><b>Q.</b> Explain L and R - why doesn't ntop double count?</p>
<p><b>A.</b> Classification is all based on what ntop SEES in the packets. ntop sees packets and ONLY packets. Packets have a FROM and a TO address. Which
packets ntop sees is determined by the interfaces it is monitoring.
</p>
<p> Traffic (packets) is classified based on the joint classification of the
FROM address (L or R) and the TO address (L or R).
</p>
<p> Only in L->L traffic will ntop see sent=rcvd and 'double count'.
</p>
<pre>
Host: 192.168.1.x www.yahoo.com
L->R R->L L->R R->L
S R S R S R S R
192.168.1.x>www.yahoo.com
HTTP GET ... 30 . . . . . . 30
</pre>
<pre>
www.yahoo.com>192.168.1.x
HTTP 200 . . . 8 8 . . .
</pre>
<pre>
www.yahoo.com>192.168.1.x . . .200 200 . . .
<html>...</html>
</pre>
<pre>
etc.
</pre>
<br>
<p><b>Q.</b> Why does ntop use so much memory ?</p>
<p><b>A.</b> ntop holds a lot of information about each host it has seen in an in-memory table. Periodically, it looks at all the entries in the table and flushes any
which have been idle for a period of time.
</p>
<p> You can change the sizing of the table and the flushing interval via #define
statements in globals-defines.h.
</p>
<p> But realistically, ntop needs enough memory to hold information about what's
active on YOUR network.
</p>
<p> To reduce memory, monitor fewer protocols or use the filter (-B "bpf filter")
option to monitor only parts of the network.
</p>
<p> There have been a couple of discussions on the ntop mailing list about ntop's
memory usage - you might read them (search on gmane).
</p>
<br>
<p><b>Q.</b> Database.</p>
<p><b>A.</b> No way. This data just can't be stored in a database - while each record (row) is small, we're talking 1000s of updates/second. As in Enterprise Oracle class
speeds...
</p>
<p><b>A.</b> ntop's memory usage for host tables depends on the # of hosts it sees in packet traffic. This is NOT, repeat NOT controllable by ntop in ANY way.
If a user kicks off a port scan, 100s of hosts appear. If somebody does a
DOS attack against you, 1000s of hosts 'appear'. If a user searches Kazza
for an obscure song, it can probe 4K hosts. etc.
</p>
<p> Lots of those hosts appear, have a few bytes of traffic and then disappear.
Each host has a variable amount of memory - there's a base structure, some
optional counter structures and a large # of pointer fields, which may or
may not be valued for any given host. It depends on the # of active
sessions and a lot of other things, but 8-20K is a good guess - I usually
use 12K as an guestimating size. Similarly, sessions may appear and
disappear (http: opens a lot, does a small retrieval and closes them), ssh
may last for days. etc. Memory is consumed tracking them too.
</p>
<p> It's not just one table entry per host - there are a lot of ancillary tables
which only get allocated if you have data for them.
</p>
<br>
<p><b>Q.</b> Got a guess?</p>
<p><b>A.</b> Sure. Look in textinfo.html and you will see the line:</p>
<pre>
(very) Approximate memory per host.....4.4KB
</pre>
<p> I'm not sure how much I trust this and I wrote it. This calculation just
computes the (current usage - baseline) / # of hosts.
</p>
<br>
<p><b>Q.</b> So ntop's memory usage is dependent upon?</p>
<br>
<p><b>Q.</b> So what does the purge do?</p>
<p><b>A.</b> ntop purges idle hosts. Period.</p>
<p> Idle being defined as having not had packet traffic for a #define able
period, 5 minutes by default.
</p>
<p> Because of the amount of linked data, these purges take time (lots of
free() calls on all those char* values), so we don't purge in 'real time'.
First we build a list of idle hosts, then we purge from that list.
Any idle host is eligible for purge (unless you tell ntop not to purge idle
hosts, which is usable only on small networks).
</p>
<p> Over time, all idle hosts are purged. Only to be perturbed by the
next burst of activity - say a port scan or everybody logging in back
in after lunch. Eventually, there's some form of steady state, but it's
HIGHLY dependent upon network activity. Which, remember, is external to
ntop and can't be predicted.
</p>
<br>
<p><b>Q.</b> Why?</p>
<p><b>A.</b> Think about the overhead of sorting this huge structure by 'last packet seen time'. 1GB of ram is something like 80K+ hosts and takes a long
time to sort (let alone free). During which time, on that busy network,
a couple of dozen packets are processed... Meaning maybe your list of idle
hosts is wrong.
</p>
<br>
<p><b>Q.</b> So how about a hard memory limit?</p>
<p><b>A.</b> There's no way to make a hard limit without purging ACTIVE hosts (or non-IDLE given ntop's definition of idle).
</p>
<p> Think about it ... you're at that 1GB limit and you find a new host.
Do you kick off an interim purge (with it's huge overhead?) And wait
2 or 3 s for an available slot?? While 1000s of other packets appear??
</p>
<br>
<p><b>Q.</b> Soft limit?</p>
<p><b>A.</b> It might, might, be possible as a soft limit - but it's got a lot of issues.
</p>
<p> First off, tracking memory usage of the hosts tables is itself a huge
job. There are multiple places were stuff is purged, added to the
structures as pointers, etc. and there's a queue of purged entries
for reuse to cut down on the malloc() calls.
</p>
<p> Secondly, the purge is resource intensive, and has been the cause of
deadlocks before - you don't dare lock the structures for too long -
packets keep arriving, and FAST on the busy network that has the memory
issues in the first place. Since you can't lock for long, you can only
purge a small # of entries.
</p>
<br>
<p><b>Q.</b> But what about -x and -X.</p>
<p><b>A.</b> Ah, yes, grasshopper - you have been reading the man page. Good user. The -x and -X options are pretty crude. They say "if you have allocated
n (hosts|sessions), fail the allocation of (host|session) n+1".
</p>
<p> It works in the context of preventing memory exhaustion - if you can calculate
the right values based on your available memory (and remember that 4K or 12K or
whatever per host value is an AVERAGE).
</p>
<p> And, no, you can't make them memory dependent - it's all ultimately virtual and
ntop doesn't get indication of whether a malloc() call causes swapping. It either
works because the allocation (total) is under your limit (or the hard limit of real
memory + swap space - OS usage), or it fails.
</p>
<p> This type of limit can't make sure you save only the RIGHT hosts.
</p>
<br>
<p><b>Q.</b> These options aren't very smart, are they?</p>
<p><b>A.</b> No. They don't know anything about the hosts. Just the # of them. So failing an allocation might hurt in that the n+1th host might be an important one and yet
host #2 is basically trivial junk (the printer that sends and "I'm here" message
every three minutes).
</p>
<p> It also causes overhead, because the next packet for host n+1 will attempt to
allocate a record and fail. Again and again.
</p>
<p> But these options may keep ntop from crashing and that's a good thing.
</p>
<p> If you use them, I would recommend setting them very high - just at the limit
of what your memory permits. Use this as a last resort - say you get hit by
a worm or virus.
</p>
<p> I recommend that you use other options such as filter and track-local-hosts for
the day-to-day controls on what ntop tracks.
</p>
<br>
<p><b>Q.</b> Why does ntop drop packets?</p>
<p><b>A.</b> We used to have an extensive discussion here. But with Luca's merge of ntop-ht into baseline, we shouldn't be dropping packets beyond whatever the OS is dropping.
</p>
<p> Until we've learned enought about ntop 3.2 and following, the whole discussion
has been moved to FAQarchive.
</p>
<br>
<p><b>Q.</b> ntop stops capturing packets, except ARP and other broadcasts. Why?</p>
<p><b>A.</b> Check if you have a daemon running that periodically checks for and resets interfaces in promiscuous mode? If that happens, all you
would see were broadcast packets like ARPs...
</p>
<p> Check back in the log and see if there is a message about the interface
changing status. Determine why.
</p>
<br>
<p><b>Q.</b> How much horsepower do I need to run ntop on a network of size x?</p>
<p><b>A.</b> Nobody really knows. ntop needs enough memory to store the active hosts and enough cpu to keep up with the average packet flow. The
buffer will handle the occasional peak, but if you see frequent
lost packets, you're in trouble.
</p>
<p> Note that a few packets occasionally lost isn't a big deal for most
users. After all, the network itself has losses - I've seen my AT&T
Broadband connection have spurts of 30% packet loss. Ideally in a
LAN environment, the packet loss should be down in the small #s...
the Ethernet standard allows 1 error in 100,000,000(10^8), but most
vendors beat that by a long margin (even as high as 1 in 10^12).
</p>
<p> Of course, those are lab measurements. In the real world? Not that good.
Electrical noise can be a real bugaboo. Remember, at a certain point, if
the NIC doesn't understand what it's seeing, it throws it away and
declares an error. The key is to keep up with the traffic.
</p>
<p> Similarly, the OS kernel does the same thing in it's interrupt handling
(throw away packets). Last resort, but better than hanging up the whole
machine.
</p>
<p> ntop drops packets when the queue gets longer than the permitted length.
You can see this in the configuration page as # Queued Pkts to Process
and # Max Queued Pkts.
</p>
<p> One or two or a small number (you pick your tolerance) is ok, but constant
losses isn't. What I'm saying is that as long as ntop can keep up with the
NIC, then the data is as good as it gets... if ntop can't keep up, then the
data isn't very good.
</p>
<p> If you have measurements - network size, traffic flow and %CPU used (with
the hardware info, of course), shoot them over to us on ntop and someday
maybe we'll be able to give better #s.
</p>
<br>
<p><b>Q.</b> What about my Frobozz Model xx Magic Network card? Is it good enough?</p>
<p><b>A.</b> Probably. Well, a lot of the cheapos just don't have the buffering and cpu offload of a 3c905c or such. If the network isn't that busy,
anything will do. For a busy network, buy a decent PCI NIC.
</p>
<br>
<p><b>Q.</b> Gigabit Ethernet?</p>
<p><b>A.</b> No clue. Remember that you can suck a lot more traffic over that network than an old PC can handle (i.e. the bandwidth limitations
of 32bit PCI and PC100/133 RAM, heck even PC2700 DDR).
</p>
<br>
<p><b>Q.</b> Do "zero copy" drivers help?</p>
<p><b>A.</b> Yeah. Maybe. Once upon a time, I read about "zero copy" - look here http://people.freebsd.org/~ken/zero_copy/ for the FreeBSD stuff. Quoting:
</p>
<pre>
"What is "zero copy"?
</pre>
<pre>
Zero copy is a misnomer, or an accurate description, depending on how
you look at things.
</pre>
<pre>
In the normal case, with network I/O, buffers are copied from the user
process into the kernel on the send side, and from the kernel into
the user process on the receiving side.
</pre>
<pre>
That is the copy that is being eliminated in this case. The DMA or
copy from the kernel into the NIC, or from the NIC into the kernel is
not the copy that is being eliminated. In fact you can't eliminate
that copy without taking packet processing out of the kernel altogether.
(i.e. the kernel has to see the packet headers in order to determine
what to do with the payload)
</pre>
<pre>
Memory copies from userland into the kernel are one of the
largest bottlenecks in network performance on a BSD system, so
eliminating them can greatly increase network throughput, and
decrease system load when CPU or memory bandwidth isn't the
limiting factor."
</pre>
<p> What's that mean? It means that BEST CASE, you have to copy the data
NIC->Kernel and without zero copy, it happens TWICE. Then, once you're
in the kernel, it has to hand the data off to libpcap (another copy)
and from libpcap to ntop. So we're moving the data 3 or 4 times...
best case!
</p>
<p> Let's do some off the cuff math. Looking here
</p>
<pre>
http://www6.tomshardware.com/mainboard/20020501/ddr400vsrambus-05.html
shows a table of memory types and max bandwidth (picking a few):
</pre>
<pre>
Label Name Effective Clock Data Bus Bandwidth
PC100 SDRAM 100 MHz 64 Bit 0,8 GB/s
PC133 SDRAM 133 MHz 64 Bit 1,06 GBb/s
PC2700 DDR333 166 MHz 64 Bit 2,7 GB/s
</pre>
<p> See the problem? A fully loaded GigE link is 1 Gb/s. 4x that is 0.5
GB/s - so if ALL that's going on is the capture of packets from the network,
the CPU can keep up. Maybe. Those bandwidth numbers are theoretical, best
case (nice sequential access). Throw in some other system activity, cache
misses and CAS/RAS issues... and um...
</p>
<p> The moral is that if you're going to use ntop to monitor big fat links,
you need screaming fast iron.
</p>
<br>
<p><b>Q.</b> Can I disable logging? Totally?</p>
<p><b>A.</b> No.</p>
<br>
<p><b>Q.</b> I'm seeing weird "hosts" on my network with names like "Bridge Sp. Tree/OSI Route".
What are they?
</p>
<p><b>A.</b> There is a list of "special" MAC address prefixes in vendor.c, specialMacInfo[]. There are blocks of MAC addresses reserved (sometimes not
formally) for special uses, such as sharing information about Spanning Tree
for bridges. These do not have an IP address - they operate at a lower
level - so nothing gets displayed in some of ntop's fields.
</p>
<p> A reference about protocols at the wire level is here:
</p>
<pre>
http://www.oreillynet.com/pub/a/network/2001/03/02/net_2nd_lang.html
</pre>
<p> If you only want to see TCP/IP, then I suggest you use -B "ip" to filter
only TCP/IP protocol on your ntop line...
</p>
<br>
<p><b>Q.</b> How do I see fully qualified names for all my hosts? Some are netbios names!
</p>
<p><b>A.</b> ntop doesn't SEND NetBIOS queries, it sniffs them off the traffic already on the network.
</p>
<p> There is only ONE case where ntop uses the NetBIOS names, which is if
it can't resolve them via DNS (both it's own queries and from sniffing
responses to other's queries off the network).
</p>
<p> So, if you have a properly functioning DNS, you'll see DNS names. If
these are (for example) internal names, unknown to the DNS server, you'll
see NetBIOS names if they are available. Lastly, you'll get IP addresses...
</p>
<p> If you do have a DNS, and the name is resolved as part of the default
domain, you won't see a fully qualified name back from the DNS, so ntop
won't have that information.
</p>
<p> So, on a real network you'll often get a mix of name resolution types:
</p>
<pre>
Host IP Address MAC Address
Other Name(s)
netnews.attbi.com 63.240.76.16
tigger.homeportal.2wire.net 192.168.0.xx 00:D0:09:xx:xx:xx
homeportal.homeportal.2wire.net 192.168.0.1 00:D0:9E:xx:xx:xx
swallowtail 192.168.0.XX 00:A0:CC:xx:xx:xx SWTL [DMN]
12-xxx-xxx-xxx.client.attbi.com 12.xxx.xxx.xxx 00:D0:9E:xx:xx:xx
12-xxx-xxx-yyy.client.attbi.com 12.xxx.xxx.yyy
</pre>
<br>
<p><b>Q.</b> What does this log message (and others like it) mean? **WARNING** releaseMutex() call with an UN-LOCKED mutex [hash.c:559] last
</p>
<pre>
unlock [pid 22176, pbuf.c:2598]
</pre>
<p><b>A.</b> Those messages are part of an error check in our mutex handling routines.</p>
<p> If things are working properly, then these messages tell us things are
really, really, really wrong.
</p>
<p> releaseMutex() call with an UN-LOCKED mutex means that the corresponding
accessMutex() call never occured.
</p>
<p> releaseMutex() call with an UN-INITIALIZED mutex means that the
access/release occured before the createMutex().
</p>
<p> The file/line comments, e.g. [hash:559], tell you where the access/release
was called from (e.g. hash.c @ 559) and where the last recorded release was.
</p>
<p> There are others, look in leaks.c for the entire set.
</p>
<br>
<p><b>Q.</b> How serious are they?</p>
<p><b>A.</b> None of these stop ntop from processing, but they're indications of unprotected accesses to shared data areas, which could lead to lost counts.
</p>
<p> In the development cycle after 3.1 was released, I was able to track down
and fix the remaining cause of spurious messages (but I've thought this was
fixed before).
</p>
<p> For most users, these warning messages shouldn't be ignored.
</p>
<p> The root of the problem is that POSIX mutexes are stupid and don't record
a lot of state information. To debug things like deadlock, it's really,
really, nice to know where the mutex was locked from.
</p>
<p> So ntop has added 'extra' information to the mutex data for recording this.
This added data is not protected by the mutex and could get out of sync.
So we lock a state change mutex whenever we are changing the state data.
</p>
<p> BUT: You can't hold the state change mutex while waiting for the main mutex
or you deadlock.
</p>
<p> So the 'access' call becomes this pattern (see utils.c):
</p>
<p> lock(statechangemutex)
</p>
<pre>
set state data
</pre>
<pre>
tryLock(mutex)
if(fails) {
unlock(statechangemutex)
lock(mutex) <-- which may block, but does not hold the statechangemutex!
lock(statechangemutex)
}
set state data
unlock(statechangemutex)
</pre>
<br>
<p><b>Q.</b> Threads. ugh...</p>
<p><b>A.</b> There's a good set of articles on POSIX threads at</p>
<pre>
http://www-106.ibm.com/developerworks/library/l-posix1/,
http://www-106.ibm.com/developerworks/library/l-posix2/ and
http://www-106.ibm.com/developerworks/library/l-posix3/.
</pre>
<br>
<p><b>Q.</b> What does the message "URL security(1): ERROR: Found percent in URL...DANGER... rejecting request" mean?
</p>
<p><b>A.</b> It means that ntop received a request with a percent sign (%) in it, often used as part of Unicode exploits against various web servers. Since there is
no situation where ntop should process this, we reject it.
URLsecurity in http.c is the place where these tests occur.
</p>
<br>
<p><b>Q.</b> What does the message "Rejected request from address x.y.z.t (it previously sent ntop a bad request)" mean?
</p>
<p><b>A.</b> Once you send ntop a request that URLsecurity rejects, the sending address goes into a ring buffer on a 5 minute timeout where we simply drop subsequent
requests... rather than waste cycles ignoring an attack...
</p>
<br>
<p><b>Q.</b> What are the other URL security(#) codes?</p>
<p><b>A.</b> 1. Found a % in the request (Unicode problems) 2. Found a parameter type code (//, &&, ??)
3. Found a directory transversal code (..)
4. Found a prohibited (RFC1945) character
5. Found a bad extension
</p>
<br>
<p><b>Q.</b> ntop doesn't report any traffic at all.</p>
<p><b>A.</b> Understand how ntop works: It simply listens on the interface(s) for packets, then counts and interprets them. If there aren't any packets, ntop
doesn't count things.
</p>
<p> ntop does not sample. It processes every packet it sees and counts them.
Only if there is more traffic than ntop can handle for a long period of time
will the packet queue hit it's limit and packets be lost. But this is still
not sampling.
</p>
<p> Make sure that there's traffic on the interface(s) you are using. You can
use tcpdump or a similar network sniffer tool to check.
</p>
<p> If you are on a segmented network (i.e. switched), you may not see traffic
that isn't destined for the ntop machine unless you configure the switch to
set the port for the ntop host into "mirror" or "management" mode (different
vendors call it different things, but it's a mode where ALL traffic is copied
to a specific port, regardless of which port the destination host is on).
</p>
<p> If there is more than one interface in the ntop host, perhaps you aren't
listening on the one that has traffic? Check using ifconfig:
</p>
<p> eth0 Link encap:Ethernet HWaddr 00:D0:09:77:85:B9
</p>
<pre>
inet addr:192.168.0.34 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1105906 errors:0 dropped:0 overruns:0 frame:0
TX packets:601935 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:119869887 (114.3 Mb) TX bytes:112203781 (107.0 Mb)
Interrupt:11 Base address:0xc000
</pre>
<p> If the RX and TX numbers are increasing, this shows that traffic IS
flowing...
</p>
<p> If you have an unnumbered interface (listening only), remember you need to
use -m to tell ntop what is local and what isn't:
</p>
<p> eth1 Link encap:Ethernet HWaddr 00:30:F1:54:55:00
</p>
<pre>
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:1596612 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:566953031 (540.6 Mb) TX bytes:0 (0.0 b)
</pre>
<p> You can select an interface using the '-i' flag, e.g. -i eth1 or
-i eth0,eth1.
</p>
<br>
<p><b>Q.</b> ntop doesn't understand xxxxx?</p>
<p><b>A.</b> True. IP Packets have a source address & port and a destination address & port... you MUST get your head out of the application layers and revert to
that simple concept.
</p>
<p> How does Apache handle virtual hosts? It analyzes the flow at the
application level (layer 4) not the wire/packet/protocol (layers 1, 2 and
3). It does this by re-assembling packets into a layer 4 message (e.g. GET
http://virtual.host.name.com/page.html)...
</p>
<p> Now there are some layer 4 analysis routines - virtual hosts was added in
2.2 (and the folks who have virtual hosts have been pretty pleased), ftp,
http, and some others - mostly looking for traffic on non-standard
ports, etc.
</p>
<p> So, since ntop works at the packet level, it doesn't understand virtual
hosts. Unless it's SPECIFICALLY coded for. ntop is a NETWORK analyzer, not
an application level one.
</p>
<br>
<p><b>Q.</b> tcpwrappers doesn't work</p>
<p><b>A.</b> Oh yes it does... for http: connections</p>
<p> 1) You have to configure it this way before compiling ntop:
</p>
<pre>
./configure --enable-tcpwrap
</pre>
<p> 2) You must have the headers and libraries installed on the build machine
</p>
<pre>
(and on the execution machine if they aren't the same).
</pre>
<p> Remember to make the appropriate entries in hosts.allow (e.g.
ntop:192.168.0.) and hosts.deny (e.g. ntop:ALL)
</p>
<p> However, tcpwrappers and https:// is known not to work - see docs/KNOWN_BUGS
</p>
<br>
<p><b>Q.</b> My filter doesn't work! I'm running ntop like this:</p>
<pre>
/usr/local/bin/ntop -u nobody -L -d -E -w 3000 \
-m 192.168.10.0/24,xxx.xxx.xxx.xxx/32 \
-M -i eth0,eth1 \
(src net 192.168.10.0/24 or src host xxx.xxx.xxx.xxx ) \
and not dst net 192.168.10.0/24
</pre>
<p><b>A.</b> Yup, it doesn't work. Use the -B option and put the filter in quotes:</p>
<pre>
-B "(src net 192.168.10.0/24 or src host xxx.xxx.xxx.xxx ) and
not dst net 192.168.10.0/24"
</pre>
<p> ntop used to assume anything it didn't recognize was a filter. But not since
2.1.3. If you try this now, you should see a log warning that says maybe you
forgot the quotes
</p>
<br>
<p><b>Q.</b> I have experienced problems defining multiple filters: ntop reports 'syntax error'
</p>
<p><b>A.</b> If you believe the filter is syntactically correct then it's likely that the Libpcap you have used has been compiled using an old non-reentrant version of
flex. Please make sure you're using version 2.5.4 or above.
</p>
<br>
<p><b>Q.</b> Can you give some additional examples of filters?</p>
<p><b>A.</b> man tcpdump -- see "expression"</p>
<p> A couple of simple examples, courtesy of B. Loic:
</p>
<pre>
-B "host not 192.168.1.100 and not 192.168.1.101"
</pre>
<p> to exclude hosts 192.168.1.100 and 192.168.1.101 from tracking (FQDN
such as www.yahoo.com will work too).
</p>
<p> If you need to exclude a full IP range, you will want to use something like
</p>
<pre>
-B "net not 192.168.1.0/24"
</pre>
<br>
<p><b>Q.</b> What about the backtrace?</p>
<p><b>A.</b> Sadly, probably useless. Why? Too much information isn't available:</p>
<pre>
Here's one (and a pretty good, obvious one at that):
</pre>
<pre>
ntop[23720]: **FATAL_ERROR** RRD: caught signal 11 SIGSEGV
ntop[23720]: **FATAL_ERROR** RRD: BACKTRACE: backtrace is:
ntop[23720]: **FATAL_ERROR** RRD: BACKTRACE: 1. /usr/bin/ntop [0x42028c48]
ntop[23720]: **FATAL_ERROR** RRD: BACKTRACE: 2. /usr/bin/ntop(getopt_long+0x43) [0x420c4e83]
ntop[23720]: **FATAL_ERROR** RRD: BACKTRACE: 3. /usr/lib/ntop/plugins/rrdPlugin.so(rrd_update+0x61) [0x44157f7d]
ntop[23720]: **FATAL_ERROR** RRD: BACKTRACE: 4. /usr/lib/ntop/plugins/rrdPlugin.so [0x441481a2]
ntop[23720]: **FATAL_ERROR** RRD: BACKTRACE: 5. /usr/lib/ntop/plugins/rrdPlugin.so(updateCounter+0x19) [0x44148a15]
ntop[23720]: **FATAL_ERROR** RRD: BACKTRACE: 6. /usr/lib/ntop/plugins/rrdPlugin.so [0x4414ba49]
ntop[23720]: **FATAL_ERROR** RRD: BACKTRACE: 7. /lib/i686/libpthread.so.0 [0x41138941]
ntop[23720]: **FATAL_ERROR** RRD: BACKTRACE: 8. /usr/bin/ntop(__clone+0x3a) [0x420da1ca]
</pre>
<pre>
See: It doesn't give the routines, just the hex offsets from some points in the executable.
It seems to say that rrdPlugin's updateCounter called rrd_update which called getopt_long. But
then getopt_long called something else and that's what died... plus we don't see the parameters.
</pre>
<pre>
Sometimes it works great for me on my box, because I can use the tools to figure out precisely
where it means. But often I use gdb too. Move off my box and the odds of your compile and my
compile (and our ./configure and all the tool versions) matching so that the offsets mean something
are pretty small.
</pre>
<br>
<p><b>Q.</b> What do these log messages mean?</p>
<pre>
**ERROR** mVLAN: Host (identical IP/MAC) found on multiple VLANs
mVLAN: ntop continues but will consolidate and thus probably overcount this traffic
mVLAN: Up to 10 examples will be printed
mVLAN: Host 192.168.aaa.bbb (00:12:17:xx:yy:zz) VLANs 3 and 4
</pre>
<p><b>A.</b> Once again, they mean what they say. ntop found something pretty weird. It found packets for the same 'host' (that is the same IP and MAC address) on two different VLANs. In this
case, IP 192.168.aaa.bbb, MAC 00:12:17:xx:yy:zz on VLAN 3 and VLAN 4.
</p>
<p> It's not WRONG, but it's definitely odd. If we see a packet twice, we count it twice, so -
via this message - we're warning you that we might be double counting some traffic. We warn
you ONCE per host (per ntop run) and for only up to 10 hosts, so as not to innundate you with
meaningless warnings.
</p>
<p> On the about page is a count (if you've even seen this junk), in the "Host/Session counts - global"
section. If it's just a couple, ignore it.
</p>
<p> If you see a lot of this stuff, you may want to rethink your ntop sensor placement or at least
understand what you are doing. On my home LAN, I use a 802.1q VLAN trunk to move traffic between
two switches and have a passive tap on the trunk. Traffic to/from the firewall moves over this trunk,
so I see the same packet on the YELLOW(DMZ) VLAN and the GREEN(TRUSTED) VLAN all the time.
</p>
<p> Why even bother trapping and warning? Well, there is one bad thing from ntop's perspective with
duplicated hosts, which would occur if we didn't trap this, and that is that you would also
see a lot of RRD errors when ntop tries to update the same host twice:
</p>
<p> **WARNING** RRD: rrd_update(/usr/.../ipBytesSent.rrd) error: illegal attempt to update using time
</p>
<pre>
1109523297 when last update time is 1109523297 (minimum one second step)
</pre>
<h2>Running Web Server</h2>
<br>
<p><b>Q.</b> Why does ntop display bits of my web site, instead of its own pages?</p>
<p><b>A.</b> ntop is designed to search the current working directory for data files, such as the html subdirectory, before it searches the default directories.
</p>
<p> This is a feature.
</p>
<p> You are one of those rare souls who happen to have had an unrelated
subdirectory 'html' with a file named 'index.html' as a subdirectory
of the current working directory at the time that you launched ntop.
cd to an acceptable directory, such as /usr/share/ntop, before
launching ntop.
</p>
<br>
<p><b>Q.</b> What are High/Medium/Low risk flags</p>
<p><b>A.</b> They are set in reportUtils.c based on fairly self-obvious functions Well documented in the help.html page, reachable by clicking on
the problem descriptions or via http://127.0.0.1:3000/help.html
</p>
<p> Often seen if you are monitoring a backbone or common network (high)
or if you have cloned MAC addresses for, say, a home Firewall box.
</p>
<br>
<p><b>Q.</b> What does the "Users" flag mean on a host?</p>
<p><b>A.</b> If you go to the "Info about host xxxx" page, there will be data in the "Known Users" section, if it's acting as a server for certain
protocols.
</p>
<p> In sessions.c, the function updateHostUsers() is used to maintain the list
of "users" of a host. In handleSession(), as part of the protocol level
analysis, the "user" information for various protocols is pulled out of the
packets. Stuff like the "X-Kazaa-Username" header, the "MAIL FROM:" header,
etc.
</p>
<p> We tag users as one or more of the following types:
</p>
<pre>
P2P_USER, SMTP_USER, FTP_USER, POP_USER, IMAP_USER
</pre>
<p> Note that for P2P, we also record - where possible - whether this user is
in P2P_UPLOAD_MODE and/or P2P_DOWNLOAD_MODE.
</p>
<br>
<p><b>Q.</b> Why are some of the host names in different colors?</p>
<p><b>A.</b> Colors are used on several of the ntop pages to convey extra information to the user. (in particular the ACTIVE TCP SESSIONS
and the LOCAL HOST STATS pages). There are five colors used to
depict how long ago the host was first seen by ntop.
</p>
<p> The pages which display these colors use a html style sheet called
style.css located in the normal html subdirectory (where ntop is
installed). This happens by setting the 'class=' parameter of
the html 'A' (Anchor or hyper-link) tag. The style sheet defines
the following:
</p>
<pre>
Age of host 'class' name Color code Color description
(minutes)
-------------------------------------------------------------------
0-5 A.age0min { color:#FF0000 } Red
5-15 A.age5min { color:#FF00FF } Fuchsia/Magenta
15-30 A.age15min { color:#FF7F00 } Coral (lt orange)
30-60 A.age30min { color:#007FFF } Slate blue
60+ A.age60min { color:#0000FF } Blue
</pre>
<p> The color legend is displayed on the About | Configuration page
(info.html).
</p>
<br>
<p><b>Q.</b> What does the P2P flag mean on a host?</p>
<p><b>A.</b> If ntop knows enough to tag you as a P2P user, it's also looking at the other headers to see if it can track what files you're exchanging. If a host
(i.e. a workstation) downloads a file from another host ("server"), the file
name is recorded in the list ntop maintains for both of them.
</p>
<p> If a host has at least one file name recorded, it's tagged with the "P2P"
flag.
</p>
<br>
<p><b>Q.</b> What does a "Virtual Host" mean.</p>
<p><b>A.</b> If a single instance of a web server handles many web sites, all of the references resolve to the same name. The web server uses the "Host:"
header to determine which "index.html" page to serve up.
</p>
<p> ntop monitors port 80 (http:) exchanges and looks for the Host: which allows
it to build a list of virtual hosts being handled by the web server.
</p>
<h2>Running Web Server (https:)</h2>
<br>
<p><b>Q.</b> SSL is not working! I have the following error in the log/terminal:</p>
<pre>
10/Jun/2002 22:58:17 Started thread (6151) for network packet sniffing on
eth0.1700:error:140EC0AF:SSL routines:SSL2_READ_INTERNAL:non sslv2
initial packet:s2_pkt.c:187:
</pre>
<p><b>A.</b> You forgot to put https:// instead of http:// in the URL you put in your browser!
</p>
<br>
<p><b>Q.</b> Unable to find SSL certificate 'ntop-cert.pem'</p>
<p><b>A.</b> ntop looks such file under the current working directory, then /etc or in Whatever directory you configured with ./configure.
</p>
<p> If you want a personal certificate, you need to create it by:
</p>
<pre>
>make ntop-cert.pem
</pre>
<p> It should be installed as part of "make install". If you have a special
Certificate or it's not present, do it (one-time) manually:
</p>
<p> For example to install it under /usr/local/etc, do:
</p>
<p> mkdir /usr/local/etc
cp /usr/local/bin/ntop-cert.pem /usr/local/etc/ntop
</p>
<p> See docs/README.SSL
</p>
<pre>
Q: What is the ssl watchdog?
A: Short answer: There are reported problems w/ the ntop web server hanging when
accessed via ssl (https://) from Netscape 6.2.2 (Win2K) (and
others).
</pre>
<pre>
The ssl "watchdog" keeps an eye on the web server - it waits
for 3 seconds and then if the SSL_accept call (openSSL) hasn't
finished, it aborts it. This leaves the user with nothing on
their web browser, but at least ntop's web server continues on.
</pre>
<pre>
There is no known way to send something back to the user. DON'T
EVEN ASK. It's not in ntop, it's the browser-server handshake
that's hung. So, it looks - to the user - like a failed
connection. S'be'it...
</pre>
<p> If you are using https:// and seem to have the problem, run ntop with the
--ssl-watchdog command line parameter... The item to look for on the
configuration page (info.html) is:
</p>
<pre>
# HTTPS Request Timeouts
</pre>
<p> Or messages in the log:
</p>
<p> ...: SSLWDERROR: Watchdog timer has expired. Aborting request, but ntop
</p>
<pre>
processing continues!
</pre>
<p> You can also enable it via a ./configure parameter (./configure --help |
less) if it's something you're going to always require.
</p>
<br>
<p><b>Q.</b> Tell me more</p>
<p><b>A.</b> The problem is that ntop's web server is single threaded until we determine that the request is simply one that will be reading data. At that point we
fork to generate the page. But the basic "accept a request" code is single
threaded. This happens all but instantaneously and hasn't been a problem
previously.
</p>
<p> The code is pretty basic and pretty common:
</p>
<pre>
select() to wait for a connection, then
ssl_accept() to fire up a "server", meaning the ssl handshake.
</pre>
<pre>
Then process the http request (i.e. the GET and associated headers).
</pre>
<p> With Netscape 6.2.2 (and others), there seems to be a bug in the Netscape
code (ntop's is identical to other projects like sshd).
</p>
<p> According to something I read - but now can't find again - Netscape doesn't
accept a legal combination of options on the handshake back from openSSL and
hangs in a deadly embrace. Supposedly openSSL 0.9.6c (or was it d - it's not
in the changelog) built in a patch. However, I didn't find the new version
changed the behavior.
</p>
<p> There is stuff about a bug w/ Netscape 4.x on the openSSL website, but I'm
not having trouble with Netscape 4.x.
</p>
<p> I don't understand the details and really don't care to find out. It boils
down to a hang in a call, SSL_accept() that doesn't have a timeout parameter.
Argh
</p>
<p> Because the code is invasive, I built it (like the SIGPIPE stuff) so you can
turn it on at ./configure time:
</p>
<pre>
--enable-sslwatchdog Watchdog for ssl hangups (Netscape 6.2.2)
[default=disabled]
</pre>
<p> or via a command line option:
</p>
<pre>
--ssl-watchdog Use ssl watchdog (NS6 problem)
</pre>
<p> With the "fix", ntop's web server hangs for at most 3 seconds, then continues
on. The user gets nada - and I don't know a way to send them anything,
because we haven't retrieved the request yet nor done the handshake (so there
isn't a TCP connection!)
</p>
<p> It only affects https:// requests and I've coded the watchdog so it doesn't
activate unless we have openSSL and either the compile or runtime parameter
set. If you don't get https:// requests, it's just another idle thread.
</p>
<p> The fix is working for me... What I've tested (and the results with and
without the watchdog):
</p>
<pre>
Win2k
MS Internet Explorer 5.5 - ok
Netscape 4.61 - ok
Netscape 4.79 - ok
Netscape 6.2.2 - user gets no response
- old: ntop webserver hung and must restart ntop!!
Opera 6.03 - user gets a partial response
- old: browser says "setting up secure connection" and
never continues, but ntop's webserver is ok
(SOMETIMES you get SSL errors in log, esp.
if you cancel the browser)
</pre>
<pre>
Linux
Konqueror 2.2.2 - ok
Mozilla - 1.0 - ok
Netscape 4.78 - ok
Galeon 1.2.5 - almost complete response, browser session is toast
(must restart)
- old: user gets nothing, but the ntop webserver is ok
Opera 6.0B1 - user gets a partial response, but browser session is ok
- old: browser says "setting up secure connection" and never
continues, but ntop's webserver is ok.
</pre>
<h2>Running Web Server Security</h2>
<br>
<p><b>Q.</b> I'm being prompted for a userid/password, what do I enter.</p>
<p><b>A.</b> The default admin userid is 'Admin' (without the quotes) and the password is whatever you set on the 1st run of ntop (look in this FAQ for
--set-admin-password).
</p>
<br>
<p><b>Q.</b> Why create Userids (beyond the Admin id created by --set-admin-password)</p>
<p><b>A.</b> Multiple users allow you to control who can alter ntop's performance and/or view specific information. If you look on the "Admin" tab, you will see that
you can create additional users and also control which URLs can be executed
by whom.
</p>
<p> Userids could allow, for example, an ISP to allow users to access SOME
network performance statistics, but not the proprietary stuff...
</p>
<p> Suppose you want to restrict who accesses the Multicast statistics page,
multicastStats.html.
</p>
<p> ntop uses terminal wildcards matching the names, so multicast is treated as
multicast* and matches multicastStats.html plus any other name beginning
multicast...
</p>
<p> howto:
</p>
<p> 1st add a new user
2nd add "multicast" to the list of controlled screens and allow admin
</p>
<pre>
and the new user to access it (note the * wildcard is automatically
added)
</pre>
<p> Try and access the screen and you are prompted for a userid/password...
</p>
<p> Look in http.c for all the names and #defines used...
</p>
<br>
<p><b>Q.</b> So, How do I restrict access to the main http or https ntop web page?</p>
<p><b>A.</b> To stop everyone from logging into ntop, do the following: Select ADMIN tab
Select URL's then "Add Url"
Don't fill in anything (the wildcard * is implied)
Select only the users who you want to authorize (hold control key and
click on user to add more users if you added users)
</p>
<p> and click on "Add Url"
</p>
<p> You will see URL '*' is added, e.g.
</p>
<pre>
'showU*'
'*'
'shutdown*'
'deleteU*'
'modifyU*'
</pre>
<p> Then only users who know the user id and password (remember to keep the .db
file secure!) will have access.
</p>
<br>
<p><b>Q.</b> How good is the default security ntop provides through the web server.</p>
<p><b>A.</b> Good question...</p>
<p> The default ntop configuration is not appropriate if you put ntop in a
publicly reachable location. We assume that ntop is either running in a
small, trusted, LAN or that you've used other tools such as firewalls to
protect the ntop web server.
</p>
<p> The userid/password scheme is good enough to prevent you from accidentally
shutting down ntop or getting into 'dangerous' places. But that's really
all it does.
</p>
<p> Also, the security of the ntop web server is only as good as the security of
the passwords file, ntop_pw.db - only the ntop -u userid should be able to
read from or write to it.
</p>
<p> Read man crypt for information on the security of the encrypted password.
</p>
<br>
<p><b>Q.</b> The plugins aren't very secure.</p>
<p><b>A.</b> True.</p>
<br>
<p><b>Q.</b> How do I prevent users from turning plugins on/off?</p>
<p><b>A.</b> The default configuration of ntop does not protect the plugin pages - no password is required to access showPlugins.html.
</p>
<p> This allows any user who can connect to the ntop web server to view reports
FROM the plugins, but also allows them to make plugin configuration changes.
</p>
<p> This may not be desirable. You may wish to add additional URLs to the
Default list of those which require entry of a userid/password.
</p>
<p> You can prevent unauthorized individuals from turning plugins on/off by
adding this URL: "showPlugins.html?" to the list via Add URL.
</p>
<br>
<p><b>Q.</b> Ok, but they can still get into the configuration pages and change things.</p>
<p><b>A.</b> Yes. Add the following URLs to the controlled list:</p>
<pre>
plugins/sFlow*
plugins/netFlow*
plugins/rrdPlugin*
</pre>
<pre>
This will keep everybody who doesn't know the userid/password out of the
configurable plugins. Unfortunately, it will also prevent them from seeing
the rrd graphs, because those are created out of the rrd plugin.
</pre>
<p><b>A.</b> Instead of plugins/rrdPlugin*, create these:</p>
<pre>
plugins/rrdPlugin?d*
plugins/rrdPlugin?h*
plugins/rrdPlugin?i*
plugins/rrdPlugin?r*
</pre>
<p> It's still not perfect, the reasons why are left as an exercise for the
user.
</p>
<br>
<p><b>Q.</b> I created a new user, adminp for administering the plugins and ntop is also accepting the admin userid/password.
</p>
<p><b>A.</b> Yes, the matching of userid's isn't too swift. It's better to make sure that there are NO common initial substrings among ANY of the userids.
</p>
<pre>
Q: How can I use Apache (with it's security, etc.) to serve up ntop pages?
A: (Toby Johnson [public@tobiasly.com], Sun 10Nov2002)
</pre>
<p> A while back, I had written about the possibility of configuring ntop to use
only relative URL's, in order to facilitate proxying ntop's web interface
through Apache. I have decided it's easier to simply use Apache's ability to
rewrite ntop's URL's when necessary. So, based on my experience, here is a
mini-HOWTO on how to proxy ntop through Apache.
</p>
<p> ------
</p>
<p> Proxying ntop's web interface through a secure Apache virtual host is a
convenient way to make use of any existing security measures you may already
have. In my case, I wanted to be able to access ntop from anywhere outside
my LAN, but opening another port on my server for ntop's dedicated web
server wasn't an option.
</p>
<p> I already had a password-protected, secure web server that I use for admin
purposes -- I'll call it https://admin.tobiasly.com. I wanted ntop's web
interface to appear as a subdirectory under this host:
https://admin.tobiasly.com/ntop/ .
</p>
<p> Here's how to configure such a setup. Change the server names and ports to
match your own. I'm assuming that you already have a working, secure Apache
virtual host (using HTTPS).
</p>
<p> First, pick a port for ntop's HTTP server. I'll use 15123. You won't need
ntop's built-in HTTPS server, since you're proxying its content through a
pre-existing Apache HTTPS server. Configure ntop to start with the correct
HTTP port, and with HTTPS disabled. Something like "ntop -d -w 15123 -W 0".
(See the ntop man page for more startup options.)
</p>
<p> Now, you need to tell Apache that anything under the /ntop/ URL should be
proxied to the ntop web server. In my case, the Apache server is running on
the same machine as ntop, so it's just a proxy to a different port on
localhost. In your Apache secure host configuration, add a line like this:
</p>
<pre>
ProxyPass /ntop/ http://localhost:15123/
</pre>
<p> Now, whenever Apache receives a request for something like
"https://secure.tobiasly.com/ntop/home.html", it will proxy this request to
the location "http://localhost:15123/home.html". Ntop will take it from
there, generate the web content, and pass the result back to Apache. Then
Apache passes that result back to the original client.
</p>
<p> It's important to note that you don't need to open port 15123 to the
outside, since the connection actually goes through your existing Apache
port, and then is transparently proxied by Apache on the server itself. Of
course, you don't even have to run ntop on the same machine; as long as the
Apache server can connect to ntop's port, it'll work.
</p>
<p> This is not the same as URL redirection. As far as your web browser knows,
everything is going through https://secure.tobiasly.com/ntop/. The Apache
server does all the proxy work behind the scenes, and simply serves up the
results to the requesting client. And since the "outward-facing" server is
Apache instead of ntop, you'll be using your existing Apache secure server
certificate, instead of ntop's ntop-cert.pem.
</p>
<p> Everything appears to work OK at first, but we quickly run into a problem:
some of the URL's that ntop generates are absolute. For example, to draw bar
graphs, ntop's web pages will request the image "/gauge.jpg". This would
translate into "https://secure.tobiasly.com/gauge.jpg". Also, host info
pages are absolute. If I click on the host "10.1.2.3", it tries to take me
to the page "https://secure.tobiasly.com/10.1.2.3.html".
</p>
<p> This is a big problem, because unless the URL is underneath the /ntop/
directory, Apache doesn't know that it needs to proxy the request to ntop,
and you get broken links. Luckily, Apache has the Rewrite module that lets
us fool with requested URL's. In order to get the required URL's rewritten,
add the following to your Apache secure virtual host configuration:
</p>
<pre>
RewriteEngine On
RewriteCond %{HTTP_REFERER} tobiasly.com/ntop
RewriteCond %{REQUEST_URI} !^/ntop
RewriteCond %{REQUEST_URI} !^/error
RewriteRule ^/(.*)$ http://secure.tobiasly.com/ntop/$1 [L,P]
</pre>
<p> In English, this basically says "If I get a URL request that comes from a
page that has tobiasly.com/ntop in it, and that request doesn't begin with
/ntop, rewrute the URL to begin with http://secure.tobiasly.com/ntop/, and
pass this rewritten URL to the Proxy engine." At this point, the Proxy
engine will see that it is getting a URL that begins with /ntop/, and
correctly pass it to the ntop web server. Rewriting the request to begin
with HTTP instead of HTTPS may seem incorrect, but since that URL will be
handed directly to the Proxy engine, it can't be HTTPS or ntop's web server
will not recognize it.
</p>
<p> Now, you should be able to simply connect to
https://secure.tobiasly.com/ntop/ , and you're ready to go!
</p>
<p> NOTE courtesy of Bruno Lebayle <lebayle@esrf.fr>
</p>
<p> I had many problems with the "Rewrite" stuff described in the FAQ. After
some Google search, it appears that HTTP_REFERER is sometimes not
reliable, and the browser I am using (Firefox/Solaris) does not seem to
present this header properly.
So I've found an other way to do it, and this proves to work with many
different browsers:
</p>
<p> within mod_proxy.c:
</p>
<pre>
ProxyPass /ntop/ http://localhost:3000/
ProxyPassReverse /ntop/ http://localhost:3000/
</pre>
<p> <IfModule mod_rewrite.c>
</p>
<pre>
RewriteEngine On
RewriteLogLevel 0
RewriteLog logs/rewrite_log
RewriteCond %{REQUEST_URI} !^/$
RewriteCond %{REQUEST_URI} !^/home.html$
RewriteCond %{REQUEST_URI} !^/ntop/
RewriteRule ^/([^/]+\.[a-z]+)$ http://nms.my.domain:my_port/ntop/$1[L,P]
</IfModule>
</pre>
<p> Where http://nms.my.domain:my_port is:
- the host where the network management tools are located with the
proper authentication
- the host where the above Apache config has to be set
- the host where ntop is installed on port 3000 in this example
Where the Web site on this host has no URL in the form of /xxx.xxx aprt
from / and /home.html (additions can be made in the RewriteCond)
</p>
<p> Especially, the trailing "/" after /ntop in the RewriteCond is
mandatory, since e.g. the Ntop logo is /ntop_logo.gif and would match
/ntop
</p>
<p> # Rewrite help summary:
# HTTP_REFERER = pattern in the name of the page from which the request comes
# THIS IS NOT RELIABLE AND DIFFERS AMONG BROWSERS !!!
# REQUEST_URI = contents of the request (^ = start of line, $ = end of line,
# ! = not the text which follows
# All conditions preceding a rule are evaluated
# All rules are processed in sequence
# Rewrite: () = group of text used for the substitution,
# . = any char, * = repeated 0-N times,
# + = repeated 1-N times, ^ = not this char, [chars] = one of chars
# special characters escaped by \ e.g. the dot as \.
# $1 means the 1st group of text between ()
# Flags L = last (i.e. exit from the rewriting process)
# P = proxy (i.e. use the proxy module for this URL)
#
# Full doc in http://httpd.apache.org/docs/1.3/mod/mod_rewrite.html
# Useful help in http://rewrite.drbacchus.com/rewritewiki/
</p>
<h2>Running Web Server i18n</h2>
<br>
<p><b>Q.</b> Is ntop localized for language x? (i18n)</p>
<p><b>A.</b> No. ntop wasn't really written with i18n in mind.</p>
<p> Most of the text is generated in-line, on the fly. Plus ntop must
dynamically support multiple locales simultaneously.
</p>
<p> However, beginning with v2.1.56 (2.2 development release), there is limited,
optional, i18n support in ntop.
</p>
<br>
<p><b>Q.</b> So, what internationalization (i18n) support does ntop provide.</p>
<p><b>A.</b> The key word is LIMITED</p>
<p> This only applies to the pages that are pulled from .html files, NOT those
created internally. This includes the menus and the few static text pages,
but none of the pages with interesting data on them.
</p>
<p> The localized pages must be placed in parallel directories to the existing
html ones.
</p>
<p> For example, if ntop is installed in /usr/share/ntop, the html files are in
/usr/share/ntop/html.
</p>
<p> To support them Canadians, then, you would need to create a
/usr/share/ntop/html_en_CA AND that locale would need to be installed on the
ntop host system.
</p>
<p> Note that there are NO i18n files distributed with ntop (yet!)
</p>
<p> At ./configure time, you enable support via --enable-i18n. ntop MUST be told
how to find the locale files. In ./configure, a "standard" location is
defined per OS.
</p>
<p> (Initially only the value for FreeBSD is populated). All others assume the
"default", /usr/lib/locale. If that isn't right for your OS, then you MUST
use the optional parameter --with-localedir= to tell ntop where to find the
files.
</p>
<p> At run time, ntop scans the host for the installed locales (locale -a should
- on most systems give you a list) and checks if a comparable html_cc_XX
directory exists.
</p>
<p> This builds a list of supported languages, which (along with i18n status) is
shown on the configuration pages, info.html and textinfo.html.
</p>
<p> When an http request is made, your browser sends a list of languages it is
willing to accept in the http Accept-Language: header.
</p>
<p> (check View | Internet Options | Languages in IE to see what you're sending)
</p>
<p> For example,
</p>
<pre>
Accept-Languages: en_US, en
</pre>
<p> Means that you prefer US English, but will accept any English dialect if US
English isn't available.
</p>
<p> Be aware that the locale settings and Accept-Language settings are not well
standardized, nor common and may not necessarily map very cleanly. You
should see what's defined (perhaps it's locale 'german' instead of 'gr') and
make or link directories as necessary. You can always create the directory
you tell ntop to use via --with-localedir= in the /usr/share/ntop structure
and create links from there to the real locale directories!
</p>
<p> Limits in the per-request and total # of languages to support are in
globals-defines.h
</p>
<p> Because of directory structure limits, a lack of interest in multiple
character sets, etc. the locale and accept-language headers are coerced into
a common format:
</p>
<p> locales are ll[_XX][.char][@modifier]
</p>
<pre>
ll - language, usually the 2 character ISO abrev., such as us, it.
XX - dialect (often a country), such as CA or US (en_US != en_CA)
char - character set (we sort of assume UTF-8)
modifier - euro
</pre>
<p> Accept-Language: values are ll-XX or ll or ll-*
</p>
<p> Once the user makes a request, each page pulled is checked:
</p>
<pre>
1. For each of the Accept-Language values.
2. For the ntop host locale value.
3. In the ntop default (English) set.
</pre>
<p> These checks are performed for each of the libraries specified in the config
value (CFG_DATAFILE_DIR).
</p>
<br>
<p><b>Q.</b> What about the country flags.</p>
<p><b>A.</b> There are other sets available on the web, of different quality and size. Rather than chase down permissions and rights, we'll stick with what we have
but let you know here of other options.
</p>
<p> If you find a set you like, just download them and replace the xx.gif files
in .../html/statsicons/flags
</p>
<p> Much better, but about 4x larger:
</p>
<pre>
http://users.skynet.be/hermandw/fl/smalgifs.html
</pre>
<p> Same height, but wider (so they look better):
</p>
<pre>
http://www.kidlink.org/www/miniflags.html
</pre>
<br>
<p><b>Q.</b> What pages can be customized?</p>
<p><b>A.</b> ls /usr/share/ntop/html/*.html (or wherever the ntop pages are installed):</p>
<p> Also, remember that a file overrides ntop's internal page generation, so you
can also use this facility to override ANY of ntop's pages and return a
customized page (perhaps you don't want users seeing them?).
</p>
<h2>Running Web Server p3p</h2>
<br>
<p><b>Q.</b> What's up with P3P?</p>
<p><b>A.</b> P3P is a W3C recommendation - http://www.w3.org/TR/P3P/ - for specifying how an application(typically a web site) handles personally identifiably
information. What information the site collects and what it does with the
information.
</p>
<p> p3p is pretty complex! There are basically two ways to enable an application
for p3p. One is to add another HTTP header, P3P:. The second is to support a
well-known file location, /w3c/p3p.xml (like robots.txt).
</p>
<p> Browser support is pretty spotty, as is web site adoption.
</p>
<p> Some 3rd party browsers have some support... up to CrazyBrowser which claims
"full support", whatever that means...
</p>
<br>
<p><b>Q.</b> So why put P3P into ntop?</p>
<p><b>A.</b> It's coming. P3P is gradually making it's way into the top web sites - right now (Dec2002), for example dell.com supports it and yahoo.com doesn't.
</p>
<br>
<p><b>Q.</b> Ok, but what's that got to do with ntop?</p>
<p><b>A.</b> Since ntop collects personally identifiable data in it's access log (-a option) and it's various reports and makes those available to pretty much
anyone in the default configuration, it's probably not a bad idea to OFFER
some support. Especially if you're running ntop at a site that has started
to support P3P, if you don't have a mechanism for your own policies
you'll have to adhere to corporate ones. And that could require massive
changes to ntop.
</p>
<br>
<p><b>Q.</b> IE6?</p>
<p><b>A.</b> Since ntop doesn't send the P3P: header, IE6 ignores ntop wrt p3p. Besides, IE6 uses p3p to block 3rd party cookies. If you want to see the p3p stuff,
it's view | privacy report in the menus. If the site's policies don't match
your settings, there will be a red "do not enter" icon in the third box on
the bottom right of the IE6 window - double click on it to see the report.
See http://support.microsoft.com/default.aspx?scid=KB;en-us;q293513
</p>
<br>
<p><b>Q.</b> Mozilla</p>
<p><b>A.</b> Unknown if it's enabled by default. Mozilla had support, ripped it out in Feb 2002 and put a new version back in.
</p>
<br>
<p><b>Q.</b> Other browsers</p>
<p><b>A.</b> See their home pages or search the web. One that I know that claims "full support" (whatever that means) is at http://www.crazybrowser.com/
</p>
<br>
<p><b>Q.</b> Privacy Bird?</p>
<p><b>A.</b> A browser-add-on, AT&T's privacy bird (http://www.privacybird.com/), that I'm playing with is a lot more aggressive in supporting p3p. If Privacy bird
doesn't see the P3P: header, it then requests the "well known" file,
/w3c/p3p.xml file and gets nailed by ntop as a hostile application, since we
don't have support for returning .xml files (yet).
</p>
<br>
<p><b>Q.</b> So when & how does ntop support p3p?</p>
<p><b>A.</b> A patch in the cvs on 4Dec2002 adds minimal support for p3p -- specifically:</p>
<pre>
1) ntop will respond to queries for /w3c/p3p.xml and ntop.p3p -- returning
the ntop.p3p file, IF ONE EXISTS.
</pre>
<pre>
If the file does not exist, a 404 error is generated (vs. pre 4Dec2002
behavior of adding the address to the myGlobals.weDontWantToTalkWithYou
list).
</pre>
<pre>
2) New parameters, --p3p-cp and --p3p-uri allow you to return the P3P:
header with either or both of the parameters (cp="" or policyref="")
set.
</pre>
<pre>
ntop doesn't validate the text in any way other than the usual
stringSanityCheck().
</pre>
<p> This allows me to run the Privacy Bird and still talk to ntop. I'll admit
that option #2 is speculative, since I really don't have much of a way to
test it.
</p>
<br>
<p><b>Q.</b> But there isn't a sample .p3p file provided.</p>
<p><b>A.</b> Right.</p>
<p> Please note that there is no sample file provided. This is not an oversight.
</p>
<p> After careful consideration, I am not providing one. The reason is that a
.p3p file is intended to be a legal contract between your site and your users.
While I could provide a default file that has the right tags - as I
understand p3p - for the data ntop collects and stores, I don't want the
responsibility and/or liability.
</p>
<p> If anyone wants this "sample p3p file", I will make it available for a fee,
Provided your organization - through an appropriate officer, in writing:
</p>
<pre>
1) Acknowledges that Luca Deri, Burton Strauss and other developers of
ntop have no liability for any use(s) you make of the sample p3p file
or anything you derive from it.
</pre>
<pre>
2) You will defend us - at your expense - from any lawsuit, arbitration
proceeding, etc. filed in conjunction with your use of the sample p3p
file.
</pre>
<pre>
3) You will pay any judgments, legal expenses, etc. related to any
lawsuit, arbitration proceeding, etc. in conjunction with your use of
the sample p3p file.
</pre>
<p> Since your legal department would be nuts to agree to that I doubt it will
come up.
</p>
<br>
<p><b>Q.</b> So How do I create a .p3p file?</p>
<p><b>A.</b> There are tools available to create p3p policy files - search the web for 'p3p editor'. One that I've used is a zero cost albeit beta tool, p3peditor
from IBM (http://www.alphaworks.ibm.com/tech/p3peditor).
</p>
<h2>Networks, Network cards and Networking</h2>
<br>
<p><b>Q.</b> My security people won't let me run in promiscuous mode.</p>
<p><b>A.</b> Tough...</p>
<p> Or, use the -s option and accept the limitations...
</p>
<p> Ask them "honestly, what is the problem" - other than having an interface
in promiscuous mode is a signature of a sniffer and security folks look for
unauthorized sniffers?
</p>
<p> ntop needs promiscuous mode so that it sees the full range of traffic. Any
similar product will do the same thing.
</p>
<p> If the security people think traffic on the wire is secure, they're wrong!
Face facts - just about every Windows user, except for 2K/XP Pro (and then
only if TBTP have especially locked them down) can install the windows
version of tcpdump...
</p>
<p> If it's a checklist item, just gen up a form to "authorize" it, have the
boss and VP/CIO sign it and give it to them.
</p>
<br>
<p><b>Q.</b> What is Ethernet and TCP/IP and how do they differ?</p>
<p><b>A.</b> Both are protocols - that is the definition of how to interpret bits on wires (or in packets) into
meaningful conversations.
</p>
<p> Ethernet is the lower level, wire (or wireless) protocol,
concerned with moving the physical bits of data.
</p>
<p> TCP/IP is the higher-level protocol, which explains
how to interpret the block of bits (frame).
</p>
<p> TCP/IP uses a familiar 32-bit "IP" address, e.g.
192.168.0.1.
</p>
<p> Ethernet uses a less familiar, 48 bit unique to the NIC
(some times called "burned in") address, e.g.
00:40:05:DE:AD:00. This is called the MAC (Media
Access Control) address.
</p>
<p> FYI: The official IEEE MAC address lookup is at
</p>
<pre>
http://standards.ieee.org/regauth/oui/index.shtml
(Look up the first six digits, separated by -s, e.g. 00-40-05)
</pre>
<br>
<p><b>Q.</b> OK, but how is stuff sent from my computer to, say, Yahoo!?</p>
<p><b>A.</b> First off, your computer does a lookup - using a service called DNS (Domain Name Service) to convert www.yahoo.com
to a numeric value, such as 66.218.71.80.
</p>
<p> Then it builds a collection of characters that says send
this data from me, 192.168.0.1 to Yahoo at 66.218.71.80.
This is called a packet. That gets wrapped in an Ethernet
frame (addressed from 00:40:05:DE:AD:00 to the MAC address
of the local gateway router, 0:d0:9e:6:38:00 and squirts it
out the router.
</p>
<p> Packets are forwarded step by step along a path from you
to Yahoo by computers called routers. This is done based
on the 32 bit IP address and the router's knowledge of the
network.
</p>
<p> Each router sees a Ethernet frame addressed to it (by
MAC address), checks the TCP/IP address to figure out
where to send it next, re-wraps the TCP/IP packet in a new
Ethernet frame (with the from MAC as it's own and the to
MAC as the next hop).
</p>
<p> This happens until the TCP/IP packet reaches the final
segment (the last router). Once it reaches a router that
knows it has addresses 66.218.71.0-66.218.71.255 on one
of it's interface, the routing stops using the TCP/IP
address.
</p>
<p> The last hop is done (like each intermediate hop - at the
lowest level) based on the MAC address! Specifically, the
last router does an "ARP" (Address Resolution Protocol") query,
to find out "Who Has" address 66.218.71.80. The NIC responds
with it's MAC address:
</p>
<pre>
arp who-has www.yahoo.com tell router
arp reply www.yahoo.com is-at 0:d0:9e:6:38:00
</pre>
<p> And the packet is routed to that address.
</p>
<p> Alright, that's a bit simplified, but see Douglas Comer,
"Internetworking with TCP/IP, volume I", page 25 and 73ff.
</p>
<br>
<p><b>Q.</b> Tell me more.</p>
<p><b>A.</b> OK, gang time to teach Ethernet & TCP/IP basics one more time. With pictures...
</p>
<p> Suppose you have a network that looks like this (we'll use
impossible addresses 288 - just pretend it's ok):
</p>
<pre>
(ext) 288.1.1.1 (int) 288.2.2.1
+-----+
World+Dog ------------ + ISA + ------- LAN ----- WS 288.2.2.2
| +-----+
| |(dmz) 277.1.1.1
me 299.0.0.1 \----------- DMZ ----- MAIL 277.1.1.2
\-- WEB 277.1.1.3
</pre>
<p> ISA can be acting solely as a router or it can be acting as a NAT device.
That's irrelevant, so we assume it's not.
</p>
<p> I send you a packet. It travels the Internet and arrives at your 288.1.1.1
the ISA(router) with src=299.0.0.1, dst=288.2.2.2.
</p>
<p> Like every router along the way, ISA(router) looks at the destination
address and realizes it has to route the packet on to 288.2.2.2. So the
ISA(router) sends the packet on, out the best interface to reach 288.2.2.2.
</p>
<p> Remember, however, the TCP/IP packet is wrapped in a lower level (Ethernet)
packet at the wire level. Read your TCP/IP and Ethernet standards - the
actual delivery of packets over links is this Ethernet level and it uses the
48 bit MAC address.
</p>
<p> This "Ethernet" packet is actually what travels hop to hop to hop (you can
even see these headers if you have visibility to the traffic - it's called
the link level header by tcpdump and you'll see the 48 bit MAC addresses if
you use the -e parameter).
</p>
<p> In order to be able to handle the Ethernet level signaling, each router
rewrites the packet so that the 48 bit source MAC address it it's own
(from-router that is) and the destination MAC address is the one that
from-router has in it's tables for to-router (the next hop).
</p>
<p> So the packet looks like this, where the srcMAC and dstMAC get rewritten
each hop, so that the routers on both ends of the link know whom it's
addressed to:
</p>
<p> Hop1 (srcMAC=00:00:00:aa:aa:aa dstMAC=00:00:00:bbbbb:bb frame=IP
data=(src=299.1.1.1 dst=288.2.2.2 data="Hi!")
Hop2 (srcMAC=00:00:00:bb:bb:bb dstMAC=00:00:00:cc:cc:cc frame=IP
data=(src=299.1.1.1 dst=288.2.2.2 data="Hi!")
Hop3 (srcMAC=00:00:00:cc:cc:cc dstMAC=00:00:00:dd:dd:dd frame=IP
data=(src=299.1.1.1 dst=288.2.2.2 data="Hi!")
</p>
<p> Notice how the TCP/IP stuff isn't changed. But the MAC address is.
</p>
<p> At each hop, the NIC card, operating at the Ethernet level, sees its own MAC
address and knows to accept the packet. It passes it up the protocol stack,
where the next layer (TCP/IP) realizes it needs to be routed further on...
</p>
<p> Ultimately, the packet gets delivered to some service listening on your WS.
</p>
<p> Here's a packet capture to show you:
</p>
<p> # tcpdump -Xx -c1 -i eth0 -e
tcpdump: listening on eth0
11:49:10.809890 0:3:47:b1:xx:xx 0:e0:18:b4:yy:yy ip 118:
tigger.ssh > zebra.2714:
P 1824243567:1824243631(64) ack 2328789523 win 11792 (DF) [tos 0x10]
0x0000 4510 0068 b305 4000 4006 b1e4 c0a8 2a24 E..h..@.@.....*$
0x0010 c0a8 2a21 0016 0a9a 6cbb bf6f 8ace 8213 ..*!....l..o....
0x0020 5018 2e10 ee1a 0000 469a 3e34 eda7 549e P.......F.>4..T.
0x0030 0ec4 4847 8983 fb4f 65ea 5c3e 0bbe c325 ..HG...Oe.\>...%
0x0040 7db8 9954 dae1 55b6 54f9 cdfd ac07 a2b5 }..T..U.T.......
0x0050 ce4f
</p>
<p> So this says, the packet came from tigger (MAC address 0:3:47:b1:xx:xx) ->
zebra (MAC address 0:e0:18:b4:yy:yy)
</p>
<pre>
Within that is the tcp/ip packet, from c0a82a24 -> c0ae2a21
(192.168.42.36 -> 192.168.42.33)
</pre>
<p> Here's another one, from tigger -> router.
</p>
<p> # tcpdump -Xx -c1 -i eth0 -e host 192.168.42.1
tcpdump: listening on eth0
11:52:48.712750 0:3:47:b1:aa:aa 0:d0:9e:6:bb:bb ip 72:
tigger.32782 > homeportal.gateway.2wire.net.domain:
41356+ A? cvs.ntop.org. (30) (DF)
0x0000 4500 003a bf7e 4000 4011 a5be c0a8 2a24 E..:.~@.@.....*$
0x0010 c0a8 2a01 800e 0035 0026 ce2e a18c 0100 ..*....5.&......
0x0020 0001 0000 0000 0000 0363 7673 046e 746f .........cvs.nto
0x0030 7003 6f72 6700 0001 0001 p.org.....
</p>
<p> (0035 = port 53, so it's a dns query)
</p>
<p> And one more, from cvs.ntop.org -> tigger (which has to have passed through
the router)
</p>
<p> # tcpdump -Xx -c1 -i eth0 -e "not src net 192.168.42.0/24"
tcpdump: listening on eth0
11:53:39.688806 0:d0:9e:6:bb:bb 0:3:47:b1:aa:aa ip 69:
195.31.151.66.cvspserver > tigger.42964:
P 2566885448:2566885451(3) ack 2903504154 win 24616 <nop,nop,timestamp
389837493 85533859> (DF)
0x0000 4500 0037 5f3c 4000 2906 ad56 c31f 9742 E..7_<@.)..V...B
0x0010 c0a8 2a24 0961 a7d4 98ff 9048 ad0f f51a ..*$.a.....H....
0x0020 8018 6028 279a 0000 0101 080a 173c 72b5 ..`('........<r.
0x0030 0519 24a3 6f6b 0a ..$.ok.
</p>
<p> See the MAC address? It's the routers, not cvs.ntop.org's
</p>
<br>
<p><b>Q.</b> Why do I care?</p>
<p><b>A.</b> Because that's sometimes a problem you'll have with ntop. See ntop is nosy, so it puts the interface into promiscuous mode, where every
packet - addressed to the ntop host or not - is processed. Now the
next layer up, the tcp/ip layer will throw away any 'junk' (You can
just hear it going tisk, tisk, tisk). But libpcap can intercept them
at the Ethernet level and feed them to ntop...
</p>
<p> For REMOTE hosts, ntop uses the IP address as it's the only valid data.
But for LOCAL hosts, ntop prefers to use the MAC address as a way of
resolving multi-homed or multiply addressed hosts.
</p>
<p> See if you have two IP addresses assigned to the same host on your local
network, say 192.168.42.42 and 192.168.42.43, how is ntop to tell they're
the same host? Well, the MAC addresses are the same... (for some
manufacturers, e.g. Sun, ALL of the interfaces on a host use the same MAC
address).
</p>
<p> read getHostInfo() in hash.c.
</p>
<pre>
/* This is a local address hence this is a potential
multihomed host. */
</pre>
<pre>
if((el->hostIpAddress.s_addr != 0x0)
&& (el->hostIpAddress.s_addr != hostIpAddress->s_addr)) {
isMultihomed = 1;
FD_SET(FLAG_HOST_TYPE_MULTIHOMED, &el->flags);
}
</pre>
<p> i.e. if the address we've stored for this host doesn't match this one,
it's multihomed.
</p>
<pre>
} else if((hostIpAddress != NULL)
&& (el->hostIpAddress.s_addr == hostIpAddress->s_addr)) {
/* Spoofing or duplicated MAC address:
two hosts with the same IP address and different MAC
addresses
*/
</pre>
<pre>
if(!hasDuplicatedMac(el)) {
FD_SET(FLAG_HOST_DUPLICATED_MAC, &el->flags);
...
}
</pre>
<pre>
setSpoofingFlag = 1;
hostFound = 1;
break;
}
</pre>
<p> If the addresses DO match, we've had two MAC addresses, so this is being
spoofed.
</p>
<p> etc.
</p>
<br>
<p><b>Q.</b> So why do I get bad output?</p>
<p><b>A.</b> If, somehow, you've confused ntop - for example telling it that 277.1.1.0/24 in the ascii art example (above) is local, then ntop
is going to believe you. And it will see a packet with the
277.1.1.1 IP and a MAC address. And use that. Only it's not the MAC
address of the MAIL host, it's really the MAC address of ISA.
</p>
<p> No matter, ntop doesn't know this -- all it sees is the packets and
the data you gave it. So later on, when it sees a packet with the
same MAC address, but a different IP, well, it will assume that it's
the same host... and the data will all be lumped together.
</p>
<br>
<p><b>Q.</b> Does that explain why I'm seeing xxxx as multihomed?</p>
<p><b>A.</b> Maybe. Remember - it only takes one packet, not even an ack, for ntop to create a host record. If that's wrong, it will carry
forward - and you'll probably see the host tagged as 'Multihomed'
when correct packets show up. Say:
</p>
<pre>
Host 1: IP 192.168.1.1 MAC 00:00:00:aa:aa:aa
Host 3: IP 192.168.1.3 MAC 00:00:00:cc:cc:cc
</pre>
<p> If somebody has the incorrect hosts table, dns, cached, whatever
but has the info that Host 1 is 192.168.1.3 and is on the same
subnet, then it will send a packet where the Ethernet layer and
the ip are nonsense. But because it's on the same wire, the ip
is ignored:
</p>
<p> (Ethernet from:00:00:00:dd:dd:dd to:00:00:00:aa:aa:aa)
</p>
<pre>
(tcp s=192.168.1.4 d=192.168.1.3)
</pre>
<p> ntop will read both out of the packet and create the association
</p>
<pre>
192.168.1.3=00:00:00:aa:aa:aa
</pre>
<p> Since it doesn't know better.
</p>
<p> Then when it sees
</p>
<p> (Ethernet from:00:00:00:ee:ee:ee to:00:00:00:cc:cc:cc)
</p>
<pre>
(tcp s=192.168.1.5 d=192.168.1.3)
</pre>
<p> It will create the multihomed association...
</p>
<br>
<p><b>Q.</b> So what's a hub vs. a Switch</p>
<p><b>A.</b> A hub is a device that links a bunch of computers together at the wire (Ethernet) level. Logically, Ethernet is a bus,
that is everybody sees all the traffic, just like cars crossing
under a highway bridge. Physically, Ethernet is wired like
a star - with all the wires coming back to a central "hub".
The hub is just the device that makes the electric star look
like a shared bus.
</p>
<p> Switches and Hubs operate at the Ethernet level, not TCP/IP.
</p>
<p><b>A.</b> Watch out for 'Switched hubs', which are hubs that include an internal switch between 2 or more segments (for example, BUT
NOT LIMITED TO a 10BaseT and 100BaseT) segment. These are hubs
within a segment, but switches across segments. ntop may not
see the traffic you expect if you have a 'switched hubs' and
manufacturers are pretty bad about marking them. See
http://article.gmane.org/gmane.linux.ntop.general/5081
</p>
<p><b>A.</b> A switch is a smart hub.</p>
<p> Switches improve performance by creating a virtual Ethernet
bus for the duration of the packet that joins JUST the source
and destination ports.
</p>
<p> A switch operates via an internal table of MAC addresses.
It learns (or is programmed) that 0:d0:9e:6:38:00 is on
port 1, while 00:40:05:DE:AD:00 is on port 3.
</p>
<p> A packet coming in port 1, destined for 00:40:05:DE:AD:00
is sent out ONLY port 3.
</p>
<p> If the switch doesn't know (or the packet is a broadcast),
it gets sent out all ports.
</p>
<p> This doesn't make for MORE bandwidth, but it does use it
more efficiently. That is in addition to the session between
ports 1 and 3 at 100Mbps, a second, simultaneous 100Mbps
session can occur between ports 2 and 4.
</p>
<br>
<p><b>Q.</b> How do I use ntop in a switched network?</p>
<p><b>A.</b> First off, you need to be or have the support of your network administrator. (Yes, you can do something
called "ARP poisoning" to - maybe - get the switch to send
you all the traffic, but that's beyond this FAQ... STFW)
</p>
<p> Many switches (although not the USD$50 cheap "workgroup" units)
have a special port or mode, where by all the traffic for the
entire network gets copied out that port, in addition to the
normal switch action.
</p>
<p> When you invoke the monitoring mode (called span, mirror, monitor,
analysis, etc.), you are forcing the entire switch bandwidth out one
port. This may exceed the bandwidth of the port. 100Mbps+100Mbps
>> 100Mbps!
</p>
<p> Traffic that is being sent to the monitoring port in excess of the
capacity of that port is usually dropped. It should NOT slow down
the switch on other ports.
</p>
<p> Some switches have some buffering capability and it *may* be able to
keep up with an occasional burst of traffic, as long as the average
is below the port capacity and the buffer isn't exceeded.
</p>
<p> See, for example, http://www.cisco.com/warp/public/473/41.html#archXL.
</p>
<p> One list of switch manufacturers is the document is titled "REFERENCE:
Configuring a Switch to Monitor All Traffic" from Elron Software. (The
URL is long, do a Google search for "site:elronsoftware.com wi6038").
</p>
<h2>Dumping data</h2>
<br>
<p><b>Q.</b> Can I use ntop from php/perl?</p>
<p><b>A.</b> Yes you can. Please see the www directory under the ntop source tree.</p>
<p><b>A.</b> Look at the Admin | Dump Data page.</p>
<h2>rrd (myrrd)</h2>
<br>
<p><b>Q.</b> How do I save data between runs?</p>
<p><b>A.</b> Use rrd.</p>
<br>
<p><b>Q.</b> What's rrd?</p>
<p><b>A.</b> There's a 12 page writeup on what rrd is and what ntop does with it. A pdf version is posted at SourceForge in the "Documentation" release.
Download it and read it.
</p>
<br>
<p><b>Q.</b> Do I gotta?</p>
<p><b>A.</b> Yup - the pretty pictures won't work in this FAQ.</p>
<br>
<p><b>Q.</b> I'm lazy - What is rrd?</p>
<p><b>A.</b> RRD stands for "round-robin database". It is a special type of database designed for holding sequences of information over periods of time, without growing in size.
</p>
<p> Rrdtool is a tool for manipulating RRDs. The home page for rrdtool is at
http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/
</p>
<p> What do they do? Well, suppose you want to compute the average of the traffic to your
web site for the last fifteen minutes. If you record the data each minute and save it
in a traditional database it looks like this:
</p>
<pre>
10:45 1.00 MB
10:46 1.02 MB
10:47 0.27 MB
...
11:00 0.54 MB
...
</pre>
<p> While you have the data to compute the total, the database grows in size forever. And
all you really need are the last 15 values. Certainly you can create a purge routine
and periodically remove the old data. But this type of constantly growing SQL database
- even with a prune process - will require reorganization and rebuilds over time.
</p>
<p> Suppose you had some kind of data structure where the last value was thrown away each
time you added a new one. When it comes time to store the 11:01 value, you overlay the
10:46 value. At any time, you still have the last 15 values. That - slightly simplified -
is an RRD. The benefit is that your database never grows in size. The down side is that
everything else in your history is gone - if your needs ever change, tough.
</p>
<p> The ring buffers are called round-robin archives or RRAs. The RRA actually stores the
RATE (bits per second), so the 10:47 value of 0.27 Megabytes is 0.27 * 1024*1024 * 8 / 60
or 37748.736 (bits per second). But it functions just like the rings described above.
</p>
<p> ntop uses RRDs to store data over long periods of time. Separate files are created for
each counter, in a structure that reflects the interfaces and hosts ntop sees. The specifics
of what's recorded - interfaces or not, hosts or not, etc. is controlled by switches on the
ntop rrd plugin.
</p>
<p> (Read the paper - it goes on from here, with specific details on how ntop uses RRDs).
</p>
<br>
<p><b>Q.</b> What's myrrd?</p>
<p><b>A.</b> ntop includes a frozen and slightly patched version of rrd 1.0.49 in the ntop source tree. This is called myrrd.
</p>
<p> rrdtool 1.0.49 was released 08-Aug-2004.
</p>
<pre>
1.0.50 was released 25-Apr-2005.
</pre>
<p> rrdtool 1.2.x began to be released in Apr 2005.
</p>
<br>
<p><b>Q.</b> What's rrdtool?</p>
<p><b>A.</b> rrdtool is the packaged program to access the various rrd routines (export, dump, graph) from the command line.
</p>
<br>
<p><b>Q.</b> How do I get it?</p>
<p><b>A.</b> The myrrd version included with ntop doesn't have rrdtool. Assuming you haven't installed an rrdtools package (which ntop ignores), here is how to get rrdtool:
</p>
<p> The myrrd version is a frozen copy of rrdtool 1.0.49, so your best bet is to go to the
rrdtool home page, http://www.rrdtool.com/ or the download page,
http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/pub/ and download rrdtool-1.0.49.tar.gz.
</p>
<p> Once you have it, it's pretty standard.
</p>
<p> $ tar xfvz rrdtool-1.0.49.tar.gz $ cd rrdtool-1.0.49 $ ./configure
</p>
<p> (You can add --prefix=/usr if you want)
</p>
<p> $ make
</p>
<p> This runs a few minutes.
</p>
<p> Now you can do
</p>
<p> $ make install
</p>
<p> but remember, ntop just ignores this, so why bother? All you really need are the rrdtool
executable program (src/rrdtool) and maybe a few of the files in the doc/ directory. Just
copy them where you want them and then delete the whold build directory.
</p>
<br>
<p><b>Q.</b> Where do I get rrd?</p>
<p><b>A.</b> Unless you need rrdtool, you should not need to do anything to get rrd (see myrrd, above).</p>
<p> The home page for rrd is
http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/
</p>
<p> rpm's are available at
http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/pub
</p>
<br>
<p><b>Q.</b> What about the multi-threaded development version?</p>
<p><b>A.</b> Stay away.</p>
<p> (UPDATED) I was able to patch ntop to work with 1.2.7+ and experimented with it a little bit.
</p>
<p> The binary .rrd file formats are different, so if you try 1.2.x, any new .rrd files which are
created are incompatible.
</p>
<p> The new version doesn't use freetype, it uses libart, which introduces a different (not better,
nor worse) chain of dependencies.
</p>
<pre>
Q: I've enabled the rrd plugin and there's no data ... there are messages in the log:
</pre>
<pre>
RRD call stack:
argv[0]: rrd_update
argv[1]: ...rrd/matrix/12.239.98.199/12.239.181.175/pkts.rrd
argv[2]: 1037289548:1
rrd_create(...) error: creating '...': No such file or directory
rrd_update(...) error: opening '...': No such file or directory
</pre>
<pre>
A: Create the rrd directory and make sure that the -u userid has read/write
access to it (typically /usr/share/ntop/rrd).
</pre>
<pre>
Q: Still nothing...
A: Remember to activate the plugin. You will need to configure it, and remember that
the default configuration does not include per-host data.
</pre>
<br>
<p><b>Q.</b> What's the difference in the Host Detail Level for RRDs?</p>
<p><b>A.</b> Low is just the bare counts, pktSent/pktRcvd and bytesSent/bytesRcvd.</p>
<p> Medium adds:
</p>
<pre>
pktDuplicatedAckSent/pktDuplicatedAckRcvd,
pktBroadcastSent, bytesBroadcastSent,
pktMulticastSent, bytesMulticastSent,
pktMulticastRcvd, bytesMulticastRcvd,
bytesSentLoc, bytesSentRem, bytesRcvdLoc, bytesRcvdFromRem,
ipBytesSent, ipBytesRcvd,
tcpSentLoc, tcpSentRem, tcpRcvdLoc, tcpRcvdFromRem, tcpFragmentsSent, tcpFragmentsRcvd,
udpSentLoc, udpSentRem, udpRcvdLoc, udpRcvdFromRem, udpFragmentsSent, udpFragmentsRcvd,
icmpSent, icmpRcvd, icmpFragmentsSent, icmpFragmentsRcvd,
ipv6Sent, ipv6Rcvd
</pre>
<pre>
NonIP:
</pre>
<pre>
stpSent, stpRcvd,
ipxSent, ipxRcvd,
osiSent, osiRcvd,
dlcSent, dlcRcvd,
arp_rarpSent, arp_rarpRcvd, arpReqPktsSent, arpReplyPktsSent, arpReplyPktsRcvd,
decnetSent, decnetRcvd,
appletalkSent, appletalkRcvd,
netbiosSent, netbiosRcvd,
otherSent, otherRcvd
</pre>
<pre>
And the per-protocol Sent/Rcvd
</pre>
<p> High adds:
</p>
<pre>
totContactedSentPeers, totContactedRcvdPeers
</pre>
<pre>
And the per-IP-protocol Sent/Rcvd, e.g. IP_HTTP...
</pre>
<br>
<p><b>Q.</b> rrdPlugin - problem with rrd/myrrd?</p>
<p><b>A.</b> By default, ntop's Makefile binds the static libmyrrd library to create ntop's rrdPlugin shared library. THIS IS DELIBERATE so that you use the myrrd library
and not some other version of rrd that's installed somewhere else on your system.
</p>
<p> Sometimes this causes problems, where there are special tricks required to tell
(a non gnu ld) loader about static (.a) libraries, which ntop doesn't have in
the Makefile nor the configureextra files.
</p>
<p> As a SHORT TERM WORK-AROUND, you can TRY this:
</p>
<pre>
$ cd myrrd
</pre>
<p> Edit Makefile --
</p>
<pre>
all: $(LIBRRD) libmyrrd.so
^^^^^^^^^^^ add this
</pre>
<p> Add these lines:
</p>
<pre>
libmyrrd.so: $(OBJECTS)
<tab>ld -shared -o libmyrrd.so $(OBJECTS)
</pre>
<p> Now do make. You should see a libmyrrd.so file.
</p>
<p> The main 'make' should now complete. Copy that libmyrrd.so file where the other
ntop library files are, and it MIGHT work.
</p>
<p> However, the whole idea behind having a static libmyrrd.a is to prevent version
conflicts and use a stable version of rrd.
</p>
<p> The right fix is to get the configureextra/<whatever> file changed.
</p>
<h2>netFlow and sFlow</h2>
<br>
<p><b>Q.</b> How do I access netFlow or sFlow data from ntop?</p>
<p><b>A.</b> You need to configure ntop as a listener.</p>
<p> First, use the appropriate plugin to set the parameters - basically the port
you want ntop to listen on. Then, using the Admin | Set Interface menu item,
switch ntop to report on the sFlow/netFlow pseudo-device (NetFlow-device or
sFlow-device).
</p>
<br>
<p><b>Q.</b> Can I use ntop as a netflow collector.</p>
<p><b>A.</b> Not in the current versions - you used to be able, but that code was removed.</p>
<h2>netFlow</h2>
<br>
<p><b>Q.</b> Which versions of netFlow.</p>
<p><b>A.</b> v5 And v1/v7/v9 - in that internally a v1/v7/v9 flow is copied to a v5 buffer and then
processed. We default/ignore fields that are different.
And nFlow - similar conversion.
</p>
<br>
<p><b>Q.</b> netFlow doesn't work.</p>
<p><b>A.</b> You MUST make sure the ntop plugin is ACTIVE. With the change to allow setting parameters while inactive, it's easy to miss that last step.
If you don't activate the plugin, you'll still have the netflow-device, but
no data on it...
</p>
<br>
<p><b>Q.</b> What's Virtual NetFlow Interface?</p>
<p><b>A.</b> Be sure and set it. It's important for pseudo-local classification, which affects L R reporting. You need to set it to the (network) and mask for
the netFlow collector. So ntop knows 'where' the data is coming from.
</p>
<br>
<p><b>Q.</b> 'splain some more, Lucy...</p>
<p><b>A.</b> OK.</p>
<p> It's best to think of netFlow like this:
</p>
<p> The physical interface which is monitoring the packets is like a
temperature probe you stick into a roast.
</p>
<p> Even though the display of the data can be right there at the probe, or
the other end of a (long) wire, or somewhere entirely elsewhere via a
wireless connection, the probe is monitoring at the tip. If it says 145F,
that's the temperature of the meat - not the oven and not the kitchen.
</p>
<p> Similarly, the netFlow data ntop is receiving is based on the probe
location.
</p>
<p> So, if you have a router and are monitoring a single interface to collect
netFlow data, then the ip address you want to give to ntop is that of
the router interface.
</p>
<p> If you are monitoring a router with more than one interface, you will
need to give ntop ONE of those addresses and use the -m | --local-subnets
option to tell it that the other addresses are also local.
</p>
<br>
<p><b>Q.</b> Where is info about netflow?</p>
<p><b>A.</b> Dale Reed pointed out a good tech doc (no flak, just the formats) for netflow</p>
<pre>
V1/5/7:
</pre>
<pre>
http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/nfc/nfc_2_0/nfc_ug/nfcform.htm
</pre>
<p> (As of Oct2003, it includes v8 and is here:)
</p>
<pre>
http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/nfc/nfc_3_0/nfc_ug/nfcform.htm
</pre>
<br>
<p><b>Q.</b> How Do I Enable NetFlow Data Export on a Cisco Device?</p>
<p><b>A.</b> To enable netFlow Data Export (NDE) from a Cisco device to an ntop netFlow receiver on port 2055 (default) at address 10.1.1.1:
</p>
<pre>
ip flow-export destination 10.1.1.1 2055
ip flow-export version 5
</pre>
<p> You may want to designate the source interface, e.g.:
</p>
<pre>
ip flow-export source Ethernet0
</pre>
<p> Enable netFlow on each interface to be monitored. netFlow normally only
captures data from each incoming packet, so to see traffic in both directions
netFlow must be enabled on both the incoming and outgoing interfaces. As an
example, for an Internet access router this would mean enabling netFlow on
both the internal (e.g. Ethernet) and the external (e.g. ISDN / Frame Relay
etc) interfaces:
</p>
<pre>
interface Ethernet0
ip route-cache flow
</pre>
<pre>
interface Dialer1
ip route-cache flow
</pre>
<p> By default netFlow will only export flow statistics shortly after the flow
Terminates or when 30 minutes have elapsed. In many environments, you want
ntop to be a bit more up to date. To change the timeout to five minutes:
</p>
<pre>
ip flow-cache timeout active 5
</pre>
<p> The following 'show' commands are useful for examining netFlow statistics
directly on the Cisco box and may assist when setting up ntop:
</p>
<pre>
show ip flow export
show ip cache flow
show ip cache verbose flow
</pre>
<p> Obviously, there is a lot more to it than this, for more information, see the
Cisco web site: http://www.cisco.com/go/netflow
</p>
<pre>
(Created by sholmes at snapshot, 02Feb2003)
</pre>
<br>
<p><b>Q.</b> Can I run ONLY w/ netFlow (Running ntop as a Collector for Net Flow only)</p>
<p><b>A.</b> Sure.</p>
<p> ntop is usually configured to capture all traffic from local interfaces. If no
interface is given (e.g. option -i|--interface is missing), the "first" interface
is taken. This value, typically eth0 on linux boxes, may not be what you wanted.
</p>
<p> If you want to use ntop as a collector for Net Flow traffic only, you may want to
supress all local traffic.
</p>
<p> In this case use -i none or --interface none.
</p>
<p> Remember to activate Net Flow plugin from Menu Admin->Plugin and to configure the
plugin by setting "Local Collector UDP Port".
</p>
<h2>sFlow</h2>
<br>
<p><b>Q.</b> What is sFlow</p>
<p><b>A.</b> The core component of the sFlow toolkit is the sflowtool command line utility. sflowtool interfaces to utilities such as tcpdump, ntop and Snort
for detailed packet tracing and analysis, NetFlow compatible collectors for
IP flow accounting, and provides text based output that can be used in
scripts to provide customized analysis and reporting and for integrating with
other tools such as MRTG or rrdtool.
</p>
<p> Some info:
</p>
<p> http://www.inmon.com/sflowTools.htm
http://www.faqs.org/rfcs/rfc3176.html
</p>
<br>
<p><b>Q.</b> I have activated the sFlow plugin in ntop. But it doesn't seem to generate any output based on the collected sflow datagrams.
</p>
<p><b>A.</b> sFlow can be a collector or a receiver or both, depending on the settings configured via the plugin.
</p>
<p> If you configure ntop as an sFlow collector, it will use sFlow data
for generating reports, treating the remote collector(s) as another
network interface - see Admin | Switch NIC.
</p>
<br>
<p><b>Q.</b> sFlow doesn't work.</p>
<p><b>A.</b> Check this out:</p>
<pre>
This talks about a bad experience I had setting up sFlow reception. For the longest
time, I could see that ntop was getting sflow packets, but no data would show up.
It turns out the switch I was exporting from didn't see any real traffic, and it was
just sending COUNTERSAMPLE packets.....
</pre>
<pre>
- - - - - - - - I figured out that it was indeed "invalid" sflow packets.
</pre>
<pre>
Apparently, sflow sends COUNTERSAMPLE and FLOWSAMPLE packets. COUNTERSAMPLE packets
give a quick look at interface counters on the machine, whereas FLOWSAMPLE packets
are actual packet fragments from IP connections. Ntop seems to simply parse,
debug_print, and discard COUNTERSAMPLE packets...which made it confusing to look at
the debug output and say "wow, lots of sflow coming in!" when in fact it was just for
show, as Burton suggested. I added more switches (with active connections) to the
switches sending sflow packets and I now have hosts with pretty graphs.
</pre>
<h2>Solaris</h2>
<br>
<p><b>Q.</b> How do I install the ntop package on Solaris?</p>
<p><b>A.</b> For instance do 'pkgadd -d ntop-2.2-solaris.i386'</p>
<br>
<p><b>Q.</b> What c compiler do I need?</p>
<p><b>A.</b> Sun's cc or gnu's gcc.</p>
<br>
<p><b>Q.</b> What about /usr/ucb/cc is that the one?</p>
<p><b>A.</b> No. cc is software you pay for. /usr/ucb/cc is a stub compiler and good for, recompiling the kernel and absolutely nothing else.
</p>
<p> The cc I mean is Sun's Commercial Compiler.
</p>
<h2>BSD FreeBSD</h2>
<pre>
During the ntop 3.2 development cycle,
we did development/testing under:
4.10 and 4.11
5.3 and 5.4
</pre>
<br>
<p><b>Q.</b> When I type 'make' it complains about a makefile error.</p>
<p><b>A.</b> Always remember to use gnu make.</p>
<p> On many *BSD systems which have other 'make's, gnu make is called gmake.
Try make --version -- if it shows a Gnu version stamp you're ok, otherwise
try gmake.
</p>
<br>
<p><b>Q.</b> I get "ntop: /dev/bpf0: Device not configured", what's wrong?</p>
<p><b>A.</b> This is because bfpX has not been configured inside the generic bsd-kernel config file.
</p>
<p> If you use generic kernel config file put "pseudo-device bpfilter 16" in
kernel config file and rebuild the kernel.
</p>
<br>
<p><b>Q.</b> I remember rumors about something not being right under FreeBSD with threads?
</p>
<p><b>A.</b> Yes. See FreeBSD bug bin/17437 at http://www.FreeBSD.org/cgi/query-pr.cgi?pr=17437
</p>
<p> Basically, due to limits in FreeBSD, there is no pthread_atfork() function.
So, when ntop does it's fork() call to create http pages, it can't fixup
the Mutexes. It wrong and could conceivably cause problems.
</p>
<p> However - ntop ran for years without the pthread_atfork() code, so we're
no worse off in 3.0 under FreeBSD than in 2.2 or 2.1...
</p>
<br>
<p><b>Q.</b> The web server problem?</p>
<p><b>A.</b> There was a flurry of problems late in the 3.0 development cycle having to do with a seeming deadlock of the ntop web server (it's actually not dead,
just walking at about 0.001KPH).
</p>
<p> Thanks to Yeoman efforts by Stanley Hopcroft, Michal Meloun and, well, me,
we have a work-around.
</p>
<p> With 3.1 we tried to automate this workaround, but fell a foul of FreeBSD's
fixes. So in 3.2 we've reverted to requiring the command line flag.
</p>
<p> If you're running under FreeBSD and have problems, use the flag, --set-pcap-nonblocking.
</p>
<p> For more on this, read the threads at gmane - look for "FreeBSD and pthreads" -
that's probably the best summary. But there's stuff on this back at least to
October 2003 - look for Stanley's problems with CPU usage.
</p>
<p><b>A.</b> Also, understand that --set-pcap-nonblocking is going to increase ntop's cpu usage. It will probably come close to pegging the CPU at 100%. Yet
strangely other processes won't seem to be impacted. (Of course, you really
should be running ntop on it's own host, anyway, right?).
</p>
<p> This is because of how the work-around is coded. ntop should step aside
briefly and let them run.
</p>
<p> Just be aware of it and don't ask on the mailing lists.
</p>
<p> It's not giant lock vs. fine grained, etc., it's really the handling of
signals (user interrupts) that is different.
</p>
<p> Say you have a process, A running.
</p>
<p> In linux, POSIX thread x is kernel process x' and POSIX thread y is kernel
process y'. Now the POSIX standard doesn't prevent thread y from receiving
a signal 'intended' for x, so you have to code for that. But when a thread
'sleeps', the process sleeps, which is something the kernel understands and
so the kernel can do other work.
</p>
<p> In a userland threads model (i.e. xBSD), POSIX thread x and POSIX thread y
are both parts of kernel process A. To implement the POSIX threading, the
thread library code creates a thread manager, thread z'. That thread receives
all signals, interupts etc. and parcels the work back out.
</p>
<p> This too is perfectly within the POSIX model.
</p>
<p> BUT: To implement the thread manager implies that the user task (A+x+y+z) is
active whenever it's waiting for ANYTHING. How well this works depends upon
the sophistication of kernel processes that recognize when the user task is
'idle', meaning it is spinning waiting for somethings, vs. doing useful work.
</p>
<p> In FreeBSD 4.x, we see that this recognition is not very sophisticated when
it comes to the bpf pseudo driver and so ntop will use 100% of the available CPU.
Even so, the scheduler bounces between tasks of equal priority, so productive
work does get done, but you see the high CPU usage charged to your task.
</p>
<h2>Linux all</h2>
<pre>
During the ntop 3.2 development cycle,
we did development and/or testing under:
Gentoo 2005.0
Fedora Core 2 and 3
</pre>
<pre>
The cvs version was run by users on many
other versions.
</pre>
<pre>
Others should certainly work and there
are many user reports of success.
</pre>
<h2>Linux RedHat</h2>
<br>
<p><b>Q.</b> "application bug: ntop(...) has SIGCHLD set to SIG_IGN but calls wait(). (See the NOTES section of 'man 2 wait'). Workaround activated."
</p>
<p> This message and the NOTES section of the man page lead me to believe
that the problem is handled but the kernel feels the need to report it
from time to time.
</p>
<p><b>A.</b> Read the NOTES section. The problem has been handled, but the kernel feels the need to report it from time to time. See the article at
http://article.gmane.org/gmane.linux.ntop.general/5304
</p>
<br>
<p><b>Q.</b> libpng version conflicts?</p>
<p><b>A.</b> See libpng, below.</p>
<h2>Win32 Common</h2>
<br>
<p><b>Q.</b> Where can I find GDBM for Windows?</p>
<p><b>A.</b> GDBM for windows can be found at http://www.roth.net/libs/gdbm/</p>
<br>
<p><b>Q.</b> ntop -i1 ... doesn't work</p>
<p><b>A.</b> ntop has special parameters under Win32</p>
<pre>
Under win32 there are TWO COMPLETELY SEPARATE TYPES OF PARAMETERS.
</pre>
<pre>
There are the parameters to the win32 stub AND there are parameters to ntop
itself.
</pre>
<pre>
AFTER THE win32 parameters are the ntop parameters in the standard (Unix)
-xxx format.
</pre>
<pre>
ntop /c <normal parms> runs ntop INTERACTIVELY with the specified ntop
parameters
</pre>
<pre>
ntop /i <parameters> installs ntop as a service to run with the specified parameters
</pre>
<pre>
ntop /r removes the ntop service
</pre>
<p> Remember, ntop /i and ntop /d don't actually run the service - you need to
start it.
</p>
<p> REMEMBER: there are TWO ways to run ntop, one as a service, one 'interactively' (/c).
</p>
<p> They are totally separate. Just because you ran ntop w/ interactively with some parameter
set, does not affect the stored parameter set for the service.
</p>
<p> To change the stored parameters, reinstall the service vi /i.
</p>
<br>
<p><b>Q.</b> How do I figure out what my network interface numbers are for the -I parameter?
</p>
<p><b>A.</b> (Thanks to jac engel [jacengel@home.nl] for the example)</p>
<p> If you only have ONE network interface, it doesn't matter as the default is
fine. However, that's the RARE case. Most people have multiple network
interfaces (NICs), with virtual ones for VPNs, Dialup Networking, etc.
</p>
<p> The Windows tools ipconfig, winipcfg and the Device Manager (depending on
which version of Windows you have) will probably show you them. However,
it's easier and better to use ntop to show you how ntop sees the network
interfaces.
</p>
<p> If you start ntop /c (interactive mode, with only the default parameters) it
Will display all your network interfaces (NICs), like this:
</p>
<pre>
Running ntop for Win32.
Wait please: ntop is coming up...
23/Aug/2002 20:43:55 Initializing IP services...
23/Aug/2002 20:43:55 Initializing GDBM...
23/Aug/2002 20:43:55 Initializing network devices...
23/Aug/2002 20:43:55 Found interface [index=0] '\Device\Packet_{14...1C}'
23/Aug/2002 20:43:55 Found interface [index=1] '\Device\Packet_{86...B4}'
23/Aug/2002 20:43:55 Found interface [index=2] '\Device\Packet_NdisWanIp'
23/Aug/2002 20:43:57 ntop v.2.1 MT [WinNT/2K/XP] (11/07/2002 build)
23/Aug/2002 20:43:57 Listening on [3F1C}\Device\Packet_{14...1C}
</pre>
<pre>
By default, ntop will use the lowest numbered interface. Because #s are
assigned based on the sequence cards are discovered, and this is altered if
cards are removed and added, this is often not what you want.
</pre>
<pre>
After you figure out which NIC you want, start ntop /c -i1 or -i2 or
whatever...
</pre>
<br>
<p><b>Q.</b> OK, but how to I translate \Device\Packet_xxxxx to my Froboz ModelT network card and not the Fubar27 that's on the motherboard.
</p>
<p><b>A.</b> ntop should report both the index and the human readable information.</p>
<p><b>A.</b> A Google search on script "CurrentVersion\NetworkCards" finds a couple of scripts/utilities that might work in various environments.
</p>
<p><b>A.</b> Otherwise...</p>
<p> You're going to need to view the registry. All the usual warnings - back up
your pc, etc.
</p>
<p> If you damage the registry, you may not be able to reboot the computer.
</p>
<p> You're not going to CHANGE anything, but an inadvertent keystroke could be
disaster ... BE CAREFUL!
</p>
<p> Under WinNT/2K, to find the interface name of your NIC look in the registry
at the keys in
</p>
<pre>
HKLM\Software\Microsoft\Windows NT\Currentversion\NetworkCards\
The two subkeys, Servicename and the Description tells you which id maps to
which NIC.
</pre>
<br>
<p><b>Q.</b> Where does ntop look for html (and gif) files under Win32?</p>
<p><b>A.</b> ntop looks in two places. The first is the current directory and the second is configurable through a constant in ntop_win32.h, #define DATAFILE_DIR "."
</p>
<p> Note that the current directory, or ".", may not be what you expect.
</p>
<p> When running ntop as a Win32 service, "." is %SystemRoot%\system32, meaning
that ntop looks in %SystemRoot%\system32\html for the .html and .gif files.
</p>
<p> When running ntop from the command line,
</p>
<pre>
ntop /c parameters...
</pre>
<p> "." is whatever directory is current. This means that if you run ntop with a
full, explicit path (c:\ntopnew\ntop /c ...) there may be an unexpected
difference between what ntop finds for "." and what you THINK "." is! This
will lead to missing .html and .gif files.
</p>
<p> If you wish to have ntop look in a specific place for the files, the best
choices are:
</p>
<pre>
1) Create a .bat file to run ntop which does a cd to the expected directory
first.
2) Edit ntop_win32.c and then recompile.
</pre>
<p> Note that the settings for DATAFILE_DIR (and other constants) are reported on
the text version of the configuration page, textinfo.html.
</p>
<h2>Win32 (MinGW) (Windows)</h2>
<br>
<p><b>Q.</b> What's the scoop with ntop on Windows?</p>
<p><b>A.</b> Semi-officially,</p>
<p> ntop for Windows 95/98/ME/NT/2K is also provided as a binary application with
limited capture capability (1000 packets). This is intended to allow
demonstration of ntop for people without access to a Unix system.
</p>
<p> We call this version Win32 after the old official name of the Windows library.
</p>
<p> If you want to use the full version with unlimited packet capture you can
either:
</p>
<pre>
* Recompile ntop from the source by yourself (Luca says just open the
files in MS Visual C++ 6.0 and press compile)
* Register your ntop for Windows 95/98/NT/2K copy by paying a
convenience fee to receive the prebuilt executable.
</pre>
<p> If you decide to register your copy, Luca will send you an URL from which
you can download the full version periodically.
</p>
<br>
<p><b>Q.</b> So where did MinGW come in?</p>
<p><b>A.</b> All of the necessary open software tools have been ported to run under windows (sort of), so it is theoretically possible to build and run ntop
under Windows.
</p>
<p> However, Windows and *nix are very, very different internally. So we have
to use special versions of the packet capture library (winpcap instead of
libpcap). And we needed our standard tools (gcc et al), plus some 'glue'
so we could make *nix calls and have Windows things happen.
</p>
<p> For the tools and glue, there are three choices: native, Cygwin and MinGW.
</p>
<p> Native means you put lots of #ifdefs in to make Windows calls where you
had *nix calls.
</p>
<p> Cygwin is a shim - it's a Windows dll (Dynamic Link Library) that pretends
to support the *nix calls and then does the right Windows things for you.
</p>
<p> MinGW is a project to create native Windows tools and executables from
*nix code.
</p>
<p> Each of these have limits, pluses and minuses. For example, Cygwin's dll
has caused all sorts of problems (dlls and their *nix equivalent, shared
libraries, usually do). MinGW has some limits. As MinGW grew, ntop for
Win32(MinGW) got closer to ntop under *nix. Native means supporting two
'separate' code bases.
</p>
<p> Luca actually picked a hybrid - he uses Microsoft Visual C++ 6.0 - which
has it's own (albeit incomplete) shim layer. As long as you stay within
the limits of the shim, the same code works across platforms. In other
places you have to make thinks like Windows wants them. How close are
we? grep for WIN32.
</p>
<p> The advantage of the hybrid was that is was also pretty close to working
under MinGW - creating native executables from the base code using free
tools. So people sent in patches and it pretty much worked. Up until
2.1.3, that is. But it was never officially more than an 'it also runs'.
</p>
<p> After 2.1.3, Luca embarked on a process of bringing the WIN32 and *nix
code closer together. Surprisingly, this actually broke MinGW!
</p>
<br>
<p><b>Q.</b> Where do I get MinGW?</p>
<p><b>A.</b> The MinGW home page is http://www.mingw.org. Quoting:</p>
<pre>
"MinGW is a collection of header files and import libraries that
allow one to use GCC and produce native Windows32 programs that do
not rely on any 3rd-party DLLs. The current set of tools include
GNU Compiler Collection (GCC), GNU Binary Utilities (Binutils),
GNU debugger (Gdb) , GNU make, and a assorted other utilities. We
are currently working on creating a complete set of Mingw-hosted
GNU toolchain, and looking for volunteers."
</pre>
<br>
<p><b>Q.</b> Does ntop work under Cygwin?</p>
<p><b>A.</b> The .exe distributed through ntop.org is built with Visual C++ 6.0. It proved just barely possible to use the same code under MinGW.
Forget about cygwin.
</p>
<br>
<p><b>Q.</b> Does ntop (v3.2) work under MinGW?</p>
<p><b>A.</b> Maybe (I think) - During the 3.1 development cycle changes were made to support MinGW and it should again work - see docs/BUILD-MinGW.txt
</p>
<h2>Win32 (MS Visual C++)</h2>
<h2>Libpng</h2>
<br>
<p><b>Q.</b> Bad things - I see the following messages:</p>
<pre>
libpng warning: Application was compiled with png.h from libpng-1.0.x
libpng warning: Application is running with png.c from libpng-1.2.x
gd-png: fatal libpng error: Incompatible libpng version in application
and library
</pre>
<p><b>A.</b> You have a version problem with libpng.</p>
<p> First off, following the instructions in BUILD-NTOP.txt should work just
fine. These problems come about when you have libpng installed (i.e. using
shared libraries).
</p>
<p> 1. If you are compiling from source, you may have png.h left over from the
</p>
<pre>
earlier version of libpng. Remove it.
</pre>
<p> 2. (Most common under RedHat). RedHat 7.2 installs a libgd.so.1.8.4 library,
</p>
<pre>
which was compiled against 1.0.x series of libpng (which is fine, because
RedHat 7.2 includes libpng-1.0.12).
</pre>
<p> Updating RedHat to newer (RawHide) packages for libpng,
http://www.rpmfind.net//linux/RPM/rawhide/1.0/i386/RedHat/RPMS/libpng-1.2.2-5.i386.html,
should work. However, there are reports of version conflicts and required
updates to multiple packages. Proceed with caution (especially if you decide
to uninstall 1.2.2-5).
Also, do not use --nodeps or --force, as this can leave you with two
partially installed versions (see item #1, above).
</p>
<p> 3. (Slackware) Users have reported this error from an older header file in
</p>
<pre>
/usr/include.
Make sure to run "make install" in the libpng directory so that the latest
files are in the common library locations. You can do this with buildAll.sh,
just navigate back down to the libpng-1.2.x directory first.
</pre>
<p> 4. If you are building ntop on one machine and running on another, they may
</p>
<pre>
have different libpng.so versions. Even if you think you are using the
static linked version (buildAll.sh), be careful - see the entry (above) on
"make install" for libpng.
</pre>
<br>
<p><b>Q.</b> When I run ./configure, it finds png.h but not libpng:</p>
<pre>
*******************************************************************
*
* ERROR: libpng header or library routines are missing
* (yes means it was found, no means it was not found)
*
* png.h...yes
* png_read_info() in -lpng...
*
*>>> No way to proceed.
*
*??? Install libpng (and/or libpng-devel), check www.libpng.org
*??? and Rerun ./configure
*
*******************************************************************
</pre>
<p><b>A.</b> You're missing libpng.so. Look for it (locate libpng) and tell ntop where it is via the --with-png-lib= parameter.
</p>
<br>
<p><b>Q.</b> I seem to be missing libpng.so - when I do locate libpng, it finds:</p>
<pre>
/usr/lib/libpng.so.3
/usr/lib/libpng.so.3.1.2.2
/usr/lib/libpng12.so.0
/usr/lib/libpng12.so.0.1.2.2
/usr/lib/libpng.so.2.1.0.13
but no libpng.so...
</pre>
<p><b>A.</b> Yeah. Send RedHat a nasty gram.</p>
<br>
<p><b>Q.</b> I don't understand...</p>
<p><b>A.</b> In a normal libpng install, say from the source, you would have - in addition to the .so.n.n.n.n files - a symlink named libpng.so, like this:
</p>
<pre>
lrwxrwxrwx 1 root root 19 Apr 23 15:46 libpng.so -> libpng12.so.0.1.2.2
</pre>
<p> But, that link seems to be missing. Without it, -lpng doesn't properly
resolve and you get the ./configure error.
</p>
<br>
<p><b>Q.</b> Why?</p>
<p><b>A.</b> RedHat ships Linux with both versions of libpng, a 1.0.x and a 1.2.x version.</p>
<p> Do this:
</p>
<pre>
$ rpm -qa | grep libpng
</pre>
<p> And you'll see the libpng 1.0.x run time:
</p>
<pre>
libpng-1.2.2-8
libpng-devel-1.2.2-8
libpng10-1.0.13-6
</pre>
<p> Dig into the files installed by them and you'll not find libpng.so.
</p>
<p> Since they're incompatible RedHat doesn't create the libpng.so link.
Instead they patch the makefiles to point the various packages at one or the
other .so file they install. This allows them to ship packages that require
one or the other.
</p>
<p> It works fine unless you try and install something other than via an rpm.
Then you're missing the libpng.so file that normal packages look for...
</p>
<p> Best bet is to create a symbolic link from the libpng.so.xxxx installed
by the package which matches the -devel (because that's where png.h is
found), e.g.:
</p>
<p> ln -s /usr/lib/libpng.so.3.1.2.2 /usr/lib/libpng.so
</p>
<p> And remember this in case you update the libpng rpm's in the future.
</p>
<h2>Silly Season</h2>
<br>
<p><b>Q.</b> Who is Pixel</p>
<p><b>A.</b> My cat.</p>
<h2>HowTo Ask For Help (ntop mailing lists)</h2>
<pre>
WTO ask for help on the ntop or ntop-dev mailing lists:
</pre>
<pre>
WHERE TO POST
</pre>
<pre>
ntop is for user questions - "How to I install", "data isn't being recorded",
etc.
</pre>
<pre>
ntop-dev is for code and development questions. The ntop-dev list goes to fewer
people, those who have self-selected themselves to be interested in ntop at the
code level.
</pre>
<pre>
ntop-misc is for other products - nProbe, nBox, PF_RING, etc.
</pre>
<pre>
Discussions about the current cvs version belong in ntop-dev.
</pre>
<pre>
If a discussion gets too technical, you may be asked to "move it to ntop-dev".
Please honor that request (even if you have to subscribe for a while - ntop-dev
is fairly low traffic).
</pre>
<pre>
There used to be mailing lists and trackers at SourceForge, which were rarely
looked at and have been discontinued. Use the ntop and ntop-dev lists (go to
http://www.ntop.org to signup for them).
</pre>
<pre>
OFFICIAL vs UNOFFICIAL
</pre>
<pre>
A response from Luca Deri should be considered official. He is the author of
ntop and controls the project and it's destiny.
</pre>
<pre>
***Please understand that the mailing lists are a community support effort***
</pre>
<pre>
Besides Luca Deri, a number of people answer questions to the best of our
ability. None of the rest of the people who may respond to your question on ntop
or ntop-dev are able to respond "officially".
</pre>
<pre>
Likewise, this HOWTO is unofficial.
</pre>
<pre>
Everyone is welcome to help with the evolution of ntop - that is to find
problems, create and test patches and send them in to patches@ntop.org for
inclusion. There are a small number of people with write access to the cvs,
but anything we commit is subject to being ripped out by Luca for any reason...
or no reason at all...
</pre>
<pre>
QUESTION FORMATS
</pre>
<pre>
ONE QUESTION per message, and you MUST use meaningful message subjects - one's
that would have helped YOU find the prior discussion of this or a similar
problem in the archives. Titles such as "urgent" or "ntop problem" will often
not get a response - it may be urgent to you but it's probably not an issue
for others.
</pre>
<pre>
WE STRONGLY SUGGEST YOU USE THE BUILT IN AUTOMATICALLY GENERATED PROBLEM
REPORT (About | "bug icon"). This includes most of the internal configuration
data we ask for (and more) and has blank spots for you to fill it.
</pre>
<pre>
Generate one, cut & paste into your mail client, edit the data and sent it.
</pre>
<pre>
Beyond that, don't worry -- it's about information, not format.
</pre>
<pre>
RESPONSES
</pre>
<pre>
Despite any individual's frequent postings, nobody is "responsible" for
answering your question. It's all on a "best efforts" basis. Our responses may
be incomplete, inaccurate, even dead wrong. Caveat Emptor! The only "guarantee"
is that free support will be worth what you've paid for it. It may be worth MORE,
it won't be worth LESS.
</pre>
<pre>
Just because you post a question does NOT mean that you are OWED an answer.
</pre>
<pre>
If nobody answers, then maybe it's because:
</pre>
<p> * Nobody knows.
* People are busy.
* You've asked the same question multiple times and it's already been
</p>
<pre>
answered.
* You have been asked for additional information and are unable/unwilling
to supply it.
</pre>
<pre>
or, well, any one of a dozen other reasons.
</pre>
<pre>
Asking the same question multiple times - or asking it again because you don't
like the answer you received - is a slap in the face of the person who took the
time to answer you in the first place and will more than likely not get a
different response. If you're not sure that your message posted, check the
archives to see if your message is there -- please don't just keep reposting it.
</pre>
<pre>
You can always use gmane (http://www.gmane.org) to see the last 600 or so
postings to the lists.
</pre>
<pre>
Please direct all original postings and subsequent replies to the list, not to
someone privately. Most of us will reply solely to the mailing list, unless
you specifically request otherwise. If you do request otherwise, the individual
you sent it to may choose not to respond. Our posting here is NOT a public
invitation to invade our e-mail boxes for your free private support.
</pre>
<pre>
THE BACK AND FORTH PROCESS
</pre>
<pre>
"Why don't you just fix my problem instead of asking for more information?"
</pre>
<pre>
Understand that we can't see your machine (and wouldn't want the
responsibility of sshing into somebody else's box as root). The only
information we have is what you post and the responses to our questions. Few
failures in ntop are related to the core processing routines - so if you're
having a problem, it's most likely because of some combination of your network
and your ntop configuration. It may be unique to you -- and only with YOUR help
can it be resolved.
</pre>
<pre>
WHAT IS SUPPORTED?
</pre>
<pre>
Releases are hosted at SourceForge.
</pre>
<pre>
At the time of this writing the stable version is 3.0. What support is available
is for the development version ("the cvs"). All support is in the form of
fixing things in the cvs.
</pre>
<pre>
However we also attempt to support the current "stable" release (3.0).
</pre>
<pre>
Older versions are not supported -- especially 1.3 and the 2.0.99 series of
2.1 release candidates. If you have a problem with them, please obtain the
current cvs version and see if it's still a problem. Unlike certain much larger
projects, we don't fix things in older versions - there simply aren't enough
resources available.
</pre>
<pre>
intop is not supported. It's gone and no longer in the cvs. For a look at
Rocco's new, work-in-progress, download ntcsh, the ntop enabled tcsh shell.
</pre>
<pre>
Please understand that the only way to fix your problem may be a source patch,
which you will have to apply, compile, install and test against the cvs version
prior to it's inclusion in the cvs.
</pre>
<pre>
If you aren't capable of or willing to do these steps -- for whatever reason --
then you should not be compiling from the cvs.
</pre>
<pre>
CVS
</pre>
<pre>
The cvs is at http://cvs.ntop.org, userid is anonymous, password ntop.
</pre>
<pre>
The cvs is a DEVELOPMENT version. The code in the cvs is subject to rapid
change. At any point in time, it may not compile. It may not compile with
certain options or on some platforms. s'be'it -- it's a DEVELOPMENT version.
</pre>
<pre>
3.1
</pre>
<pre>
The actual flow of ntop development was 3.0.50.. ->
-> 3.0.50.. -> 3.1rc1 -> 3.1
</pre>
<pre>
3.2
</pre>
<pre>
The actual flow of ntop development was 3.1.1.. -> etc (I think .4 was the last Win32 version),
-> 3.1.50.. -> 3.1.51 -> 3.2rc1 -> 3.2rc2 -> 3.2
</pre>
<pre>
FEE-BASED SUPPORT
</pre>
<pre>
If you want better than "best-efforts" support, contact the individual you
Desire support from off-list to make financial arrangements. Please understand
that people are doing development in areas that are of personal interest to
them, to improve ntop.
If you want to discuss payment for support or a specific change that is of
Interest to you, feel free to email the individual off-list - some of us are
Computer consultants and can be bought, with the understanding that the work
product is offered back to the community in the spirit of the open source
movement and the strictures of the GPL.
</pre>
<pre>
SO WHAT INFORMATION SHOULD I POST?
</pre>
<pre>
BEFORE POSTING:
</pre>
<pre>
1. Please review the output from ./configure.
</pre>
<pre>
We all have the bad habit of skipping over this, but there are often
warnings which explain why things don't work. ntop tries to build itself by
turning off features where the required libraries and/or headers aren't
available.
The minimum required set is just that - minimal. This is often the source
of "feature x or switch y doesn't work" reports.
</pre>
<pre>
2. Please review the docs/FAQ file.
</pre>
<pre>
3. Please review back message traffic from the mailing lists.
</pre>
<pre>
Yes, we know that there isn't a search function at ntop.org. Did you know
that the lists are spidered every couple of months or so and can be
searched through Google?? For example, "site:lists.ntop.org rpm" will find
mail list messages with the word "rpm" in them.
</pre>
<pre>
Do you know about gmane (http://www.gmane.org) has archives (searchable) of
the ntop lists going back into late 2001. The lists are called
</pre>
<pre>
gmane.linux.ntop.devel
gmane.linux.ntop.general
</pre>
<pre>
You can read these online (the last 600 messages or so) or through the nntp
server.
</pre>
<pre>
POSTING:
</pre>
<pre>
Do not worry about posting TOO much information - we're pretty good at filtering
out the noise.
</pre>
<pre>
WE STRONGLY SUGGEST YOU USE THE BUILT IN AUTOMATICALLY GENERATED PROBLEM
REPORT (About | "bug icon"). This includes most of the internal configuration
data we ask for (and more) and has blank spots for you to fill it.
</pre>
<pre>
Generate one, cut & paste into your mail client, edit the data and sent it.
</pre>
<pre>
If you can't or won't use the automated problem report (say, for example you
can't get ntop up to generate it) - don't worry -- it's about information, not
format. Send us what you can, organized this way:
</pre>
<pre>
1. A brief summary of the problem.
</pre>
<pre>
2. Operations
The EXACT command line you use to invoke ntop.
If it's in a script, cut & paste it and
resolve all the variables!
</pre>
<pre>
Error Messages: Cut & paste the exact text.
If it's in the log, give us 15 or 20 lines before.
</pre>
<pre>
The exact URL you used from the browser.
</pre>
<pre>
3. Software
ntop version, source and any applied patches
</pre>
<pre>
If you've compiled from the source, say so!
</pre>
<pre>
If you're using a package (such as an .rpm), where
did you get it from and what is the EXACT name,
version information and date? (for example, post
the output from rpm -q ntop -i)
</pre>
<pre>
OS vendor & version
</pre>
<pre>
gcc version (e.g. gcc --version)
(For ./configure problems, the versions for autoconf, automake and
libtool too)
</pre>
<pre>
glibc version
</pre>
<pre>
Any major upgrades (kernel, networking, etc.)
</pre>
<pre>
What else is running
</pre>
<pre>
4. Hardware
Type & # of processors
</pre>
<pre>
Amount of memory
</pre>
<pre>
# network interfaces and types (vendor, bus, etc.)
</pre>
<pre>
5. Network
Roughly where are the interface(s) you're monitoring
(Public Internet, Private LAN, what?)
</pre>
<pre>
What's the bandwidth (e.g. 10 Mbps University internet,
1.5 Mbps T1, Cable Modem capped at 1.5Mbps, 56K dialup)
</pre>
<pre>
How many machines (traffic sources/destinations) and users
</pre>
<pre>
(If you're uncomfortable giving specifics, then leave it generic, but the
information is necessary to allow efficient use of the community's time helping
YOU with YOUR problem)
</pre>
<pre>
AFTER POSTING:
</pre>
<pre>
Please let us know if our help fixed the problem, didn't solve it or enabled you
to solve it yourself and what the result was. The historical record of the ntop
and ntop-dev archives is the complete chain from problem to resolution.
</pre>
<pre>
(Originally posted on 07Jan2002 to ntop and ntop-dev, updated. This is version 12April2003)
</pre>
<h2>GDB ultraMinitutorial Running ntop under gdb (debugger)</h2>
<h2>or, 'capturing the failure point'</h2>
<pre>
The very best way to debug a segmentation fault in ntop is to use gdb. The
Standard ntop compile already has the flags necessary to do this set.
</pre>
<pre>
(Note - if you don't have gdb, or aren't compiling yourself, this won't work)
</pre>
<pre>
> gdb /usr/bin/ntop (or wherever ntop is installed)
...
(gdb) set args (your usual arg string) -K
</pre>
<pre>
[That is, add the -K argument. While you are at it, don't give it the -d
argument and add -u root (replace any existing -u value) - yes, it's insecure
running as root, but you're not planning on doing this in production nor as a
routine situation!]
</pre>
<pre>
it will run... when it bombs...
</pre>
<pre>
"bt full" does a decent job of printing the stack and the back trace and the
local variables at each level.
</pre>
<pre>
Just make sure you are in the thread you are interested in (i.e. DO THIS FIRST)
</pre>
<pre>
(gdb) bt full
#0 0x40592557 in __libc_pause () from /lib/i686/libc.so.6
No locals.
#1 0x4046b5a3 in pause () at wrapsyscall.c:123
result = -1073743680
oldtype = 0
#2 0x0804ac1b in main (argc=22, argv=0xbffffa44) at main.c:928
argc = -1073743680
argv = (char **) 0x0
i = 0
userSpecified = 1
ifStr = "eth0,eth1", '\000'
lastTime = 1025633918
#3 0x404f3647 in __libc_start_main (main=0x804a74c , argc=22, ubp_av=0xbffffa44,
init=0x8049600 <_init>, fini=0x804d000 <_fini>, rtld_fini=0x4000dcd4 <_dl_fini>,
stack_end=0xbffffa3c) at ../sysdeps/generic/libc-start.c:129
ubp_av = (char **) 0xbffffa44
fini = (void (*)()) 0x40016b4c <_dl_debug_mask>
rtld_fini = (void (*)()) 0xbffff87c
ubp_ev = (char **) 0xbffffaa0
(gdb)
</pre>
<pre>
Now, continue:
</pre>
<pre>
if there are any seemingly interesting variables involved, you can print them:
</pre>
<pre>
(gdb) print deviceId
</pre>
<pre>
[gdb can handle pretty complex arguments in the print command, so you can say
"print myGlobals.device[0].hash_hostTraffic[myGlobals.broadcastEntryIdx]"
if that's what it bombed on.]
</pre>
<pre>
Sometimes gdb won't find a variable, that's because C used a register. S'be'it.
</pre>
<pre>
Other interesting things:
</pre>
<pre>
(gdb) list [this shows where in the code it died]
</pre>
<pre>
(gdb) info threads [this shows the status of the multiple threads]
</pre>
<pre>
(gdb) info stack [this shows the call stack]
</pre>
<pre>
If you want, you can check each of the threads and THEIR status via:
</pre>
<pre>
(gdb) thread 1 [or any valid number]
(gdb) info stack
</pre>
<pre>
gdb has all kinds of included help, and frankly that's all I know...
Here are some extracts and examples:
</pre>
<pre>
(gdb) help info thread
IDs of currently known threads.
</pre>
<pre>
(gdb) info thread
13 Thread 11276 (LWP 8967) 0x405f651e in __select () from
/lib/i686/libc.so.6
12 Thread 10251 (LWP 8966) 0x405f651e in __select () from
/lib/i686/libc.so.6
11 Thread 9226 (LWP 8965) 0x405f651e in __select () from
/lib/i686/libc.so.6
10 Thread 8201 (LWP 8964) 0x405f651e in __select () from
/lib/i686/libc.so.6
9 Thread 7176 (LWP 8963) 0x405f651e in __select () from
/lib/i686/libc.so.6
8 Thread 6151 (LWP 8962) 0x405ca071 in __libc_nanosleep () from
/lib/i686/libc.so.6
7 Thread 5126 (LWP 8961) 0x4053db85 in __sigsuspend (set=0x4300998c)
at ../sysdeps/unix/sysv/linux/sigsuspend.c:45
6 Thread 4101 (LWP 8960) 0x405ca071 in __libc_nanosleep () from
/lib/i686/libc.so.6
5 Thread 3076 (LWP 8959) 0x405ca071 in __libc_nanosleep () from
/lib/i686/libc.so.6
4 Thread 2051 (LWP 8958) 0x405ca071 in __libc_nanosleep () from
/lib/i686/libc.so.6
3 Thread 1026 (LWP 8957) 0x4053db85 in __sigsuspend (set=0x4100967c)
at ../sysdeps/unix/sysv/linux/sigsuspend.c:45
2 Thread 2049 (LWP 8956) 0x405f4e17 in __poll (fds=0x823dbec, nfds=1,
timeout=2000)
at ../sysdeps/unix/sysv/linux/poll.c:63
* 1 Thread 1024 (LWP 8952) 0x405ca027 in __libc_pause () from
/lib/i686/libc.so.6
</pre>
<pre>
The * indicates the current thread. Switch with this:
</pre>
<pre>
(gdb) thread 7
</pre>
<pre>
Once you have a thread selected, you can look at the call stack:
</pre>
<pre>
(gdb) help stack
Examining the stack.
The stack is made up of stack frames. Gdb assigns numbers to stack frames
counting from zero for the innermost (currently executing) frame.
</pre>
<pre>
At any time gdb identifies one frame as the "selected" frame.
Variable lookups are done with respect to the selected frame.
When the program being debugged stops, gdb selects the innermost frame.
The commands below can be used to select other frames by number or address.
</pre>
<pre>
List of commands:
</pre>
<pre>
backtrace -- Print backtrace of all stack frames
bt -- Print backtrace of all stack frames
down -- Select and print stack frame called by this one
frame -- Select and print a stack frame
return -- Make selected stack frame return to its caller
select-frame -- Select a stack frame without printing anything
up -- Select and print stack frame that called this one
</pre>
<pre>
Type "help" followed by command name for full documentation.
Command name abbreviations are allowed if unambiguous.
(gdb) info stack
#0 0x4053db85 in __sigsuspend (set=0x4300998c) at
../sysdeps/unix/sysv/linux/sigsuspend.c:45
#1 0x404db1c9 in __pthread_wait_for_restart_signal (self=0x43009be0) at
pthread.c:969
#2 0x404dc1ec in __new_sem_wait (sem=0x804d5c8) at restart.h:34
#3 0x402960e0 in waitSem (semId=0x804d5c8) at util.c:1126
#4 0x4027ae0f in dequeueAddress (notUsed=0x0) at address.c:425
#5 0x404d8c6f in pthread_start_thread (arg=0x43009be0) at manager.c:284
</pre>
<pre>
And select a specific frame via:
</pre>
<pre>
(gdb) select-frame 4
</pre>
<pre>
(gdb) help list
List specified function or line.
With no argument, lists ten more lines after or around previous listing.
"list -" lists the ten lines before a previous ten-line listing.
One argument specifies a line, and ten lines are listed around that line.
Two arguments with comma between specify starting and ending lines to list.
Lines can be specified in these ways:
LINENUM, to list around that line in current file,
FILE:LINENUM, to list around that line in that file,
FUNCTION, to list around beginning of that function,
FILE:FUNCTION, to distinguish among like-named static functions.
*ADDRESS, to list around the line containing that address.
With two args if one is empty it stands for ten lines away from the other
arg.
(gdb) list address.c:425
420
421 while((myGlobals.addressQueueLen == 0)
422 && (myGlobals.capturePackets) /* Courtesy of Wies-Software
<wies@wiessoft.de> */
423 ) {
424 #ifdef USE_SEMAPHORES
425 waitSem(&myGlobals.queueAddressSem);
426 #else
427 waitCondvar(&myGlobals.queueAddressCondvar);
428 #endif
429 key_data.dptr = data_data.dptr = NULL;
</pre>
<pre>
(gdb) help print
Print value of expression EXP.
Variables accessible are those of the lexical environment of the selected
stack frame, plus all those whose scope is global or an entire file.
</pre>
<pre>
$NUM gets previous value number NUM. $ and $$ are the last two values.
$$NUM refers to NUM'th value back from the last one.
Names starting with $ refer to registers (with the values they would have
if the program were to return to the stack frame now selected, restoring
all registers saved by frames farther in) or else to debugger
"convenience" variables (any such name not a known register).
Use assignment expressions to give values to convenience variables.
</pre>
<pre>
{TYPE}ADREXP refers to a datum of data type TYPE, located at address ADREXP.
@ is a binary operator for treating consecutive data objects
anywhere in memory as an array. FOO@NUM gives an array whose first
element is FOO, whose second element is stored in the space following
where FOO is stored, etc. FOO must be an expression whose value
resides in memory.
</pre>
<pre>
EXP may be preceded with /FMT, where FMT is a format letter
but no count or size letter (see "x" command).
</pre>
<pre>
(gdb) print key_data
$3 = {dptr = 0x0, dsize = 1076452514}
(gdb) print data_data
$4 = {dptr = 0x0, dsize = 4}
</pre>
<pre>
Original version Luca Deri, 1999-2001
Updated Burton M. Strauss III 2002, 2003, 2004, 2005
</pre>
<!-- Total Lines........ 5297 -->
<!-- (skipped) --s...... 66 -->
<!-- (skipped) ==s...... 13 -->
<!-- (skipped) header... 44 -->
<!-- empty ("")......... 1481 -->
<!-- empty (//)......... 11 -->
<!-- Sections........... 1 -->
<!-- Q:................. 236 -->
<!-- A:................. 239 -->
<!-- Normal text........ 1897 -->
<!-- Preformatted text.. 1278 -->
<!-- Updated.xxmmmyyyy.. 0 -->
<!-- Added.xxmmmyyyy.... 0 -->
<!-- ...........TOTAL... 5266 -->
</body>
</html>
|