+$Id$
+
+Contents:
+
+1 - Building ethereal
+2 - Building GTK+/GLib with HP's C compiler
+3 - nettl support
+4 - libpcap on HP-UX
+5 - HP-UX patches to fix packet capture problems
+
+1 - Building ethereal
+
The Software Porting And Archive Centre for HP-UX, at
- http://hpux.csc.liv.ac.uk/
+ http://hpux.connect.org.uk/
-(and with mirrors in various countries, listed on the Centre's home
-page) has ported versions, in both source and binary form, for Ethereal,
-as well as for the "libpcap", GLib, GTK+, "zlib", and CMU SNMP libraries
-that it uses.
+(with mirrors in various countries, listed on the Centre's home page;
+you may want to choose a mirror closer to you) has ported versions, in
+both source and binary form, for Ethereal, as well as for the libpcap,
+GLib, GTK+, and zlib libraries that it uses.
The changes they've made appear largely to be compile option changes; if
you've downloaded the source to the latest version of Ethereal (the
-O"; there's a comment "Add -Dhpux_9 if building under 9.X". It may
also build with GCC.
+They currently have libpcap 0.6.2; libpcap 0.6.2, and later versions,
+include changes to properly open network devices when given the name
+reported by the lanscan and ifconfig commands - earlier versions didn't
+do this correctly. Therefore, we strongly suggest you use libpcap 0.6.2
+or later, not libpcap 0.5.2.
+
+2 - Building GTK+/GLib with HP's C compiler
+
+By default, HP's C compiler doesn't support "long long int" to provide
+64-bit integral data types on 32-bit platforms; the "-Ae" flag must be
+supplied to enable extensions such as that.
+
+Ethereal's "configure" script automatically includes that flag if it
+detects that the native compiler is being used on HP-UX; however, the
+configure scripts for GTK+ and GLib don't do so, which means that 64-bit
+integer support won't be enabled.
+
+This may prevent some parts of Ethereal from compiling; in order to get
+64-bit integer support in GTK+/GLib, edit all the Makefiles for GTK+ and
+GLib, as generated by the GTK+ and GLib "configure" scripts, to add
+"-Ae" to all "CFLAGS = " definitions found in those Makefiles. (If a
+Makefile lacks a "CFLAGS = " definition, there's no need to add a
+definition that includes "-Ae".)
+
+3 - nettl support
+
+nettl is used on HP-UX to trace various streams based subsystems. Ethereal
+can read nettl files containing IP frames (NS_LS_IP subsystem) and LAPB
+frames (SX25L2 subsystem).
+It has been tested with files generated on HP-UX 9.04 and 10.20.
+
+Use the following commands to generate a trace (cf. nettl(1M)):
+
+# IP capture. 0x30000000 means PDU in and PDU out :
+nettl -tn 0x30000000 -e NS_LS_IP -f tracefile
+# X25 capture. You must specify an interface :
+nettl -tn 0x30000000 -e SX25l2 -d /dev/x25_0 -f tracefile
+# stop capture. subsystem is NS_LS_IP or SX25L2 :
+nettl -tf -e subsystem
+
+One may be able to specify "-tn pduin pduout" rather than
+"-tn 0x30000000"; the nettl man page for HP-UX 10.30 implies that it
+should work.
+
+4 - libpcap on HP-UX
+
If you want to use Ethereal to capture packets, you will have to install
-"libpcap"; the INSTALL file for "libpcap" has several comments about
-HP-UX, which you should read if you're going to install and use
-"libpcap" on HP-UX.
-
-Another note, from a mail message to the "ethereal-users" list:
-
- Date: Wed, 22 Dec 1999 09:05:47 -0600 (EST)
- From: Gerald Combs <gerald@zing.org>
- To: Lothar Seitter <lothar.seitter@arcormail.de>
- cc: ethereal-users@zing.org
- Subject: Re: [ethereal-users] permission problem with capturing
-
- On Wed, 22 Dec 1999, Lothar Seitter wrote:
-
- > running 'ethereal' under HP-UX 11 with root permission and
- > /dev/lan0 set to 777, I always get the message:
- > "There are no network interfaces that can be opened.
- > Please to make sure you have sufficient permission to
- > capture packets."
- >
- > I start ethereal with 'etheral -i lan0' and lan0 is definitely
- > the lan interface.
- >
- > What am I missing???
-
- You may need to reference the card's DLPI device directly. We were having
- trouble getting Ethereal to capture on an HP-UX 10.20 machine here. I
- found an article on Deja News that says:
-
- "To access a particular interface, you would say "tcpdump -i /dev/dlpiN"
- where N is the PPA of the interface you wish to use. You get the PPA by
- looking at the output of lanscan. On 10.20, it is the same value as the
- NMID. On 11.X, it is the Card Instance number."
-
- This didn't help in our case, but it might in yours. The full article is
- at http://x34.deja.com/[ST_rn=ps]/getdoc.xp?AN=549366486 .
-
- Another article by the same author mentions that experimental versions of
- libpcap and tcpdump are available at
- ftp://ftp.cup.hp.com/dist/networking/tools/ . The article itself is at
- http://x34.deja.com/[ST_rn=ps]/getdoc.xp?AN=558665378 .
-
-The first of those articles also says:
-
- BTW, before you have to make a follow-up post, you will find that
- unless you have the latest lan common/DLPI/driver patches installed,
- you will _not_ see the system's own outbound traffic.
-
-It appears that a consequence of the fact that HP-UX's DLPI doesn't work
-like Solaris's, in that, on Solaris, to get at the device "hme0", say,
-"libpcap" has to open "/dev/hme" and then tell it to use the 0th
-interface, whilst on HP-UX you have to go through "/dev/dlpi", you won't
-get a list of interfaces in the dialog box for "Capture:Start" - you'll
-have to do through the aforementioned song and dance to find the PPA of
-the interface you want to use, and supply the "dlpiN" name by hand (I
-think you can omit the "/dev/" in both "tcpdump" and Ethereal).
-
-The experimental stuff to which the second article refers is a STREAMS
-module that implements BPF-style filtering and buffering, an
-experimental version of "libpcap-0.4" that pushes that STREAMS module,
-and source to "tcpdump-3.4".
-
-The STREAMS module is in source form - no binary has been provided.
-It's in
-
- ftp://ftp.cup.hp.com/dist/networking/tools/bpfmod/bpfmod_0.1.tar.gz
-
-"libpcap" and "tcpdump" are in both source and binary form; they're in
-
- ftp://ftp.cup.hp.com/dist/networking/tools/bpfmod/tcpdump_bpfmod.tar.gz
-
-NOTE: the "libpcap" source has "pcap-bpfmod.c" and "pcap-dlpi.c" and
-"pcap-dlpi.c.real".
-
-"pcap-dlpi.c.real" appears to be the "libpcap-0.4" "pcap-dlpi.c"
-modified to push the BPF STREAMS module but not to do anything with it.
-
-"pcap-dlpi.c" is the same as "pcap-bpfmod.c".
-
-"pcap-bpfmod.c"/"pcap-dlpi.c" appears to have had a pile of stuff
-removed (e.g., the SunOS 5/Solaris support), and stuff added to try to
-do the "find the PPA for the interface and do the right thing" stuff
-alluded to above, and to push the BPF STREAMS module - however, it
-doesn't appear to include anything to hand the BPF filter to the STREAMS
-module or otherwise use it.
+libpcap; binary distributions are, as noted above, available from the
+Software Porting And Archive Centre for HP-UX, as well as source code.
+
+Versions of libpcap prior to 0.6 didn't handle HP-UX as well as 0.6 and
+later versions do. You should install the latest version.
+
+The source code is also available from the official home of libpcap and
+tcpdump, at
+
+ http://www.tcpdump.org/
+
+if you want a version later than the version available from the Software
+Porting And Archive Centre; however, the versions available from
+tcpdump.org might not, for example, include support for building libpcap
+as a shared library.
+
+5 - HP-UX patches to fix packet capture problems
+
+Note that packet-capture programs such as Ethereal/Tethereal or tcpdump
+may, on HP-UX, not be able to see packets sent from the machine on which
+they're running. Some articles on groups.google.com discussing this
+are:
+
+ http://groups.google.com/groups?selm=82ld3v%2480i%241%40mamenchi.zrz.TU-Berlin.DE
+
+which says:
+
+ Newsgroups: comp.sys.hp.hpux
+ Subject: Re: Did someone made tcpdump working on 10.20 ?
+ Date: 12/08/1999
+ From: Lutz Jaenicke <jaenicke@emserv1.ee.TU-Berlin.DE>
+
+ In article <82ks5i$5vc$1@news1.dti.ne.jp>, mtsat <mtsat@iris.dti.ne.jp>
+ wrote:
+ >Hello,
+ >
+ >I downloaded and compiled tcpdump3.4 a couple of week ago. I tried to use
+ >it, but I can only see incoming data, never outgoing.
+ >Someone (raj) explained me that a patch was missing, and that this patch
+ >must me "patched" (poked) in order to see outbound data in promiscuous mode.
+ >Many things to do .... So the question is : did someone has already this
+ >"ready to use" PHNE_**** patch ?
+
+ Two things:
+ 1. You do need a late "LAN products cumulative patch" (e.g. PHNE_18173
+ for s700/10.20).
+ 2. You must use
+echo 'lanc_outbound_promisc_flag/W1' | /usr/bin/adb -w /stand/vmunix /dev/kmem
+ You can insert this e.g. into /sbin/init.d/lan
+
+ Best regards,
+ Lutz
+
+and
+
+ http://groups.google.com/groups?selm=88cf4t%24p03%241%40web1.cup.hp.com
+
+which says:
+
+ Newsgroups: comp.sys.hp.hpux
+ Subject: Re: tcpdump only shows incoming packets
+ Date: 02/15/2000
+ From: Rick Jones <foo@bar.baz.invalid>
+
+ Harald Skotnes <harald@cc.uit.no> wrote:
+ > I am running HPUX 11.0 on a C200 hanging on a 100Mb switch. I have
+ > compiled libpcap-0.4 an tcpdump-3.4 and it seems to work. But at a
+ > closer look I only get to see the incoming packets not the
+ > outgoing. I have tried tcpflow-0.12 which also uses libpcap and the
+ > same thing happens. Could someone please give me a hint on how to
+ > get this right?
+
+ Search/Read the archives ?-)
+
+ What you are seeing is expected, un-patched, behaviour for an HP-UX
+ system. On 11.00, you need to install the latest lancommon/DLPI
+ patches, and then the latest driver patch for the interface(s) in use.
+ At that point, a miracle happens and you should start seeing outbound
+ traffic.
+
+[That article also mentions the patch that appears below.]
+
+and
+
+ http://groups.google.com/groups?selm=38AA973E.96BE7DF7%40cc.uit.no
+
+which says:
+
+ Newsgroups: comp.sys.hp.hpux
+ Subject: Re: tcpdump only shows incoming packets
+ Date: 02/16/2000
+ From: Harald Skotnes <harald@cc.uit.no>
+
+ Rick Jones wrote:
+
+ ...
+
+ > What you are seeing is expected, un-patched, behaviour for an HP-UX
+ > system. On 11.00, you need to install the latest lancommon/DLPI
+ > patches, and then the latest driver patch for the interface(s) in
+ > use. At that point, a miracle happens and you should start seeing
+ > outbound traffic.
+
+ Thanks a lot. I have this problem on several machines running HPUX
+ 10.20 and 11.00. The machines where patched up before y2k so did not
+ know what to think. Anyway I have now installed PHNE_19766,
+ PHNE_19826, PHNE_20008, PHNE_20735 on the C200 and now I can see the
+ outbound traffic too. Thanks again.
+
+(although those patches may not be the ones to install - there may be
+later patches).
+
+And another message to tcpdump-workers@tcpdump.org, from Rick Jones:
+
+ Date: Mon, 29 Apr 2002 15:59:55 -0700
+ From: Rick Jones
+ To: tcpdump-workers@tcpdump.org
+ Subject: Re: [tcpdump-workers] I Can't Capture the Outbound Traffic
+
+ ...
+
+ http://itrc.hp.com/ would be one place to start in a search for the most
+ up-to-date patches for DLPI and the lan driver(s) used on your system (I
+ cannot guess because 9000/800 is too generic - one hs to use the "model"
+ command these days and/or an ioscan command (see manpage) to guess what
+ the drivers (btlan[3456], gelan, etc) might be involved in addition to
+ DLPI.
+
+ Another option is to upgrade to 11i as outbound promiscuous mode support
+ is there in the base OS, no patches required.
+
+Another posting:
+
+ http://groups.google.com/groups?selm=7d6gvn%24b3%241%40ocean.cup.hp.com
+
+indicates that you need to install the optional STREAMS product to do
+captures on HP-UX 9.x:
+
+ Newsgroups: comp.sys.hp.hpux
+ Subject: Re: tcpdump HP/UX 9.x
+ Date: 03/22/1999
+ From: Rick Jones <foo@bar.baz>
+
+ Dave Barr (barr@cis.ohio-state.edu) wrote:
+ : Has anyone ported tcpdump (or something similar) to HP/UX 9.x?
+
+ I'm reasonably confident that any port of tcpdump to 9.X would require
+ the (then optional) STREAMS product. This would bring DLPI, which is
+ what one uses to access interfaces in promiscuous mode.
+
+ I'm not sure that HP even sells the 9.X STREAMS product any longer,
+ since HP-UX 9.X is off the pricelist (well, maybe 9.10 for the old 68K
+ devices).
+
+ Your best bet is to be up on 10.20 or better if that is at all
+ possible. If your hardware is supported by it, I'd go with HP-UX 11.
+ If you want to see the system's own outbound traffic, you'll never get
+ that functionality on 9.X, but it might happen at some point for 10.20
+ and 11.X.
+
+ rick jones
+
+(as per other messages cited here, the ability to see the system's own
+outbound traffic did happen).
+
+Rick Jones reports that HP-UX 11i needs no patches for outbound
+promiscuous mode support.
+
+An additional note, from Jost Martin, for HP-UX 10.20:
+
+ Q: How do I get ethereral on HPUX to capture the _outgoing_ packets
+ of an interface
+ A: You need to get PHNE_20892,PHNE_20725 and PHCO_10947 (or
+ newer, this is as of 4.4.00) and its dependencies. Then you can
+ enable the feature as descibed below:
+
+ Patch Name: PHNE_20892
+ Patch Description: s700 10.20 PCI 100Base-T cumulative patch
+ To trace the outbound packets, please do the following
+ to turn on a global promiscuous switch before running
+ the promiscuous applications like snoop or tcpdump:
+
+ adb -w /stand/vmunix /dev/mem
+ lanc_outbound_promisc_flag/W 1
+ (adb will echo the result showing that the flag has
+ been changed)
+ $quit
+ (Thanks for this part to HP-support, Ratingen)
+
+ The attached hack does this and some security-related stuff
+ (thanks to hildeb@www.stahl.bau.tu-bs.de (Ralf Hildebrandt) who
+ posted the security-part some time ago)
+
+ <<hack_ip_stack>>
+
+ (Don't switch IP-forwarding off, if you need it !)
+ Install the hack as /sbin/init.d/hacl_ip_stack (adjust
+ permissions !) and make a sequencing-symlink
+ /sbin/rc2.d/S350hack_ip_stack pointing to this script.
+ Now all this is done on every reboot.
+
+Here's the "hack_ip_stack" script:
+
+-----------------------------------Cut Here-------------------------------------
+#!/sbin/sh
+#
+# nettune: hack kernel parms for safety
+
+OKAY=0
+ERROR=-1
+
+# /usr/contrib/bin fuer nettune auf Pfad
+PATH=/sbin:/usr/sbin:/usr/bin:/usr/contrib/bin
+export PATH
+
+
+##########
+# main #
+##########
+
+case $1 in
+ start_msg)
+ print "Tune IP-Stack for security"
+ exit $OKAY
+ ;;
+
+ stop_msg)
+ print "This action is not applicable"
+ exit $OKAY
+ ;;
+
+ stop)
+ exit $OKAY
+ ;;
+
+ start)
+ ;; # fall through
+
+ *)
+ print "USAGE: $0 {start_msg | stop_msg | start | stop}" >&2
+ exit $ERROR
+ ;;
+ esac
+
+###########
+# start #
+###########
+
+#
+# tcp-Sequence-Numbers nicht mehr inkrementieren sondern random
+# Syn-Flood-Protection an
+# ip_forwarding aus
+# Source-Routing aus
+# Ausgehende Packets an ethereal/tcpdump etc.
+
+/usr/contrib/bin/nettune -s tcp_random_seq 2 || exit $ERROR
+/usr/contrib/bin/nettune -s hp_syn_protect 1 || exit $ERROR
+/usr/contrib/bin/nettune -s ip_forwarding 0 || exit $ERROR
+echo 'ip_block_source_routed/W1' | /usr/bin/adb -w /stand/vmunix /dev/kmem || exit $ERROR
+echo 'lanc_outbound_promisc_flag/W 1' | adb -w /stand/vmunix /dev/mem || exit $ERROR
+
+exit $OKAY
+-----------------------------------Cut Here-------------------------------------
git.samba.org / obnox / wireshark / wip.git / blobdiff