README.aix

   1 $Id: README.aix,v 1.5 2002/05/31 10:22:51 guy Exp $
   2
   3 libpcap 0.7.1 and later appear to work on AIX when using AIX's native
   4 BPF; that appears to work better than DLPI does.  Note that you may have
   5 to run AIX's tcpdump, as root, before configuring, building, and
   6 installing libpcap, in order to create the "/dev/bpf" devices and load
   7 the BPF driver.
   8
   9 Some earlier notes: the notes about libpcap may not apply, with libpcap
  10 0.7.1, but they're preserved here for historical reasons.
  11
  12 The glib, gtk+, and Ethereal notes still apply.
  13
  14 After much work and toil, Craig Rodrigues was able to compile libpcap
  15 and Ethereal on AIX 4.3.2.  His odyssey is document in various e-mails
  16 at http://www.ethereal.com/lists/ethereal-dev/199911/
  17
  18 Here are a few excerpts.  Note that, to configure "libpcap" to use DLPI
  19 rather than BPF (which it'll apparently use by default on AIX),
  20 specifying the flag
  21
  22         --with-pcap=dlpi
  23
  24 to the "configure" script for "libpcap" should do the trick.
  25
  26 The source code changes to Ethereal mentioned below should be in the
  27 current source tree.  The changes to the GLib configure script is in
  28 GLib 1.2.7; the changes for the "-lgdk" problem are probably still
  29 necessary in the current version of GTK+.
  30
  31 Subject: Re: [ethereal-dev] Re: [ethereal-users] Problems compiling 0.7.7 under AIX 4.3.2
  32 From: Gilbert Ramirez <gram@xiexie.org>
  33 Date: Fri, 5 Nov 1999 16:58:17 -0600
  34 To: Guy Harris <guy@netapp.com>
  35 Cc: Craig Rodrigues <rodrigc@mediaone.net>, ethereal-dev@zing.org
  36
  37
  38 On Fri, Nov 05, 1999 at 01:42:44PM -0600, Guy Harris wrote:
  39 >
  40 >
  41 > Hmm.
  42 >
  43 > Looks suspiciously similar to the previous error; have you tried
  44 > recompiling GTK+ with "xlc_r"?
  45
  46 I believe glib and gtk+ should both be compiled with xlc_r. I haven't
  47 compiled on AIX in a long time, but I think it's because glib is including
  48 pthread stuff, so the re-entrant C library, libc_r, is needed.
  49
  50
  51 Compiler Invocation
  52
  53 When compiling a multi-threaded program, you should invoke the C compiler
  54 using one of the following commands:
  55
  56 xlc_r
  57     Invokes the compiler with default language level of ansi.
  58 cc_r
  59     Invokes the compiler with default language level of extended.
  60
  61
  62 These commands ensure that the adequate options and libraries are used to be
  63 compliant with the X/Open Version 5 Standard. The POSIX Threads
  64 Specification 1003.1c is a subset of the X/Open Specification.
  65
  66 The following libraries are automatically linked with your program when using these commands:
  67
  68 libpthreads.a
  69             Threads library.
  70 libc.a
  71             Standard C library
  72
  73
  74 For example, the following command compiles the foo.c multi-threaded C source file and produces the foo executable file:
  75
  76 cc_r -o foo foo.c
  77
  78 See the cc command for more information about C For AIX.
  79
  80
  81 --gilbert
  82
  83
  84 To: ethereal-users@zing.org
  85 Subject: [ethereal-dev] AIX: gtk problem solved, now an ethereal problem
  86 From: Craig Rodrigues <rodrigc@mediaone.net>
  87 Date: Mon, 8 Nov 1999 10:46:25 -0500
  88 Cc: ethereal-dev@zing.org
  89
  90
  91 Hi,
  92
  93 After much sweat and toil, I have managed to get gtk 1.2.6 to
  94 compile and not dump core under AIX.  The solutions were to
  95 (1) apply the attached patch to the configure.in in the glib-1.2.6
  96 subdirectory
  97
  98 (2)  In the file gtk+-1.2.6/gtk/Makefile, add a link flag -lgdk to link
  99 in gdk.
 100
 101 I have submitted (1) to the gtk-devel mailing list where it has been
 102 accepted.  (2) is an uglier problem, but for now, adding -lgdk by hand
 103 seems to work.
 104
 105 Now I have a problem....I compiled gtk, and that works.
 106 I compiled ethereal (after some minor mods), and it starts,
 107 but when I click on Capture -> Start, I get:
 108
 109 "There are no network interfaces that can be opened."
 110
 111 I am running as root, so I don't think permissions are a problem.
 112
 113 Any ideas?
 114
 115 Thanks.
 116 --
 117 Craig Rodrigues
 118 http://www.gis.net/~craigr
 119 rodrigc@mediaone.net
 120
 121 *** configure.in.old    Thu Oct  7 17:27:43 1999
 122 --- configure.in        Sun Nov  7 19:34:36 1999
 123 ***************
 124 *** 795,809 ****
 125           fi
 126           if test "$ac_cv_func_getpwuid_r" = "yes"; then
 127                   AC_MSG_CHECKING(whether getpwuid_r is posix like)
 128 !                       # getpwuid_r(0, NULL, NULL, 0) is the signature on
 129 !                       # solaris, if that is not found, the prog below won't
 130 !                       # compile, then the posix signature is assumed as
 131 !                       # the default.
 132 !                       AC_TRY_COMPILE([#include <pwd.h>],
 133 !                               [getpwuid_r(0, NULL, NULL, 0);],
 134 !                               [AC_MSG_RESULT(no)],
 135 !                               [AC_MSG_RESULT(yes)
 136 !                               AC_DEFINE(HAVE_GETPWUID_R_POSIX)])
 137           fi
 138   fi
 139   if test x"$have_threads" = xposix; then
 140 --- 795,809 ----
 141           fi
 142           if test "$ac_cv_func_getpwuid_r" = "yes"; then
 143                   AC_MSG_CHECKING(whether getpwuid_r is posix like)
 144 !                       # The signature for the POSIX version is:
 145 !                       # int getpwuid_r(uid_t, struct passwd *, char *, size_t, struct passwd **)
 146 !                       AC_TRY_COMPILE([#include <pwd.h>
 147 !                                         #include <sys/types.h>
 148 !                                         #include <stdlib.h>],
 149 !                               [getpwuid_r((uid_t)0, NULL, NULL, (size_t)0, NULL);],
 150 !                               [AC_DEFINE(HAVE_GETPWUID_R_POSIX)
 151 !                               AC_MSG_RESULT(yes)],
 152 !                               [AC_MSG_RESULT(no)])
 153           fi
 154   fi
 155   if test x"$have_threads" = xposix; then
 156
 157
 158
 159 To: ethereal-dev@zing.org
 160 Subject: Re: [ethereal-dev] AIX: gtk problem solved, now an ethereal problem
 161 From: Craig Rodrigues <rodrigc@mediaone.net>
 162 Date: Wed, 10 Nov 1999 12:18:47 -0500
 163
 164
 165
 166 Hi,
 167
 168 OK, I'm getting closer and closer to this working on AIX.
 169
 170 Things I've done:
 171
 172 (1) In a bunch of places in the code I removed '//' style C++ comments
 173 which the IBM C compiler didn't like.
 174
 175 (2) I also found some places in the code like:
 176
 177 enum some_enum {  FOO, BAR, };
 178
 179 IBM C did not like the trailing "," after BAR.
 180
 181 (3) In packet-ipv6.h, IPV6_VERSION is defined, but that is already
 182 defined in <netinet/in.h> on AIX 4.3, so for now I just commented that out.
 183
 184 (4) in packet-afs.c, when it sucks in <netinet/in.h>,  in.h sucks in
 185 <sys/machine.h> which defines LITTLE_ENDIAN.  This conflicts with
 186 LITTLE_ENDIAN in globals.h.  So what I did was, in globals.h, I added:
 187
 188 #ifdef HAVE_NETINET_IN_H
 189 #include <netinet/in.h>
 190 #endif
 191
 192 So after doing all these things, I can compile ethereal and run it.
 193 I can list the
 194 correct network interfaces on my system: lo0 and en0.  However,
 195 when I start capturing packets on en0, they are all of the protocol type
 196 "TRMAC" and "TR".  The only problem is, I'm not on a Token Ring network.
 197
 198 Any ideas?
 199
 200 No. Time        Source                Destination           Protocol   Info
 201 1 0.000000    0a:30:a1:08:00:45     06:74:60:08:00:5a     TR   Token-Ring Unknown
 202 2 0.210304    0a:30:a1:08:00:45     06:74:60:08:00:5a     TR   Token-Ring Unknown
 203 3 0.926080    0a:30:a1:08:00:45     06:74:60:08:00:5a     TR   Token-Ring Unknown
 204 4 0.4236416   0a:30:a1:08:00:45     06:74:60:08:00:5a     TR   Token-Ring Unknown
 205 5 0.4712064   6f:06:74:60:08:00     5a:8a:30:a1:00:00 TR MAC Unknown Major Vector: 127
 206
 207
 208 ---------------------
 209 It turns out that libpcap was using IFT_* numbers instead of DLT_* numbers for
 210 link types. That has been fixed
 211 ---------------------
 212
 213
 214 To: tcpdump-workers@tcpdump.org
 215 Subject: [ethereal-dev] Sucess with libpcap under AIX
 216 From: Craig Rodrigues <rodrigc@mediaone.net>
 217 Date: Sat, 20 Nov 1999 03:34:50 -0500
 218 Cc: ethereal-dev@zing.org
 219
 220
 221 Hi,
 222
 223 I have managed to successfully compile and use the latest
 224 snapshot of libpcap under AIX using DLPI.  bpf is majorly
 225 brain-dead under AIX, and very unsupported.  Rather than
 226 find all the bugs in AIX's bpf, I decided to try using
 227 dlpi, which is officially supported.
 228
 229 The first step is to get the setup right.  To determine if
 230 you have the dlpi driver loaded correctly, type:
 231 strload -q -d dlpi
 232
 233 If the result is:
 234 dlpi: yes
 235
 236 then you are ready to use dlpi.
 237
 238 If you get:
 239 dlpi: no
 240
 241 Then you need to type:
 242 strload -f /etc/dlpi.conf
 243
 244 Check again with strload -q -d dlpi that the dlpi driver is loaded.
 245
 246 I had to make one minor code change to pcap-dlpi.c.  Maybe someone
 247 can explain it to me, because I am not familiar with dlpi or
 248 streams programming.  It took me hours to figure this out, because
 249 I'm not familiar with dlpi.
 250
 251 In pcap-dlpi.c, lines 316-320:
 252 #if !defined(HAVE_HPUX9) && !defined(HAVE_HPUX10_20) && !defined(sinix)
 253        if (dlbindreq(p->fd, 0, ebuf) < 0 ||
 254            dlbindack(p->fd, (char *)buf, ebuf) < 0)
 255             goto bad;
 256 #endif
 257
 258 I changed it to:
 259 #if !defined(HAVE_HPUX9) && !defined(HAVE_HPUX10_20) && !defined(sinix)
 260        if (dlbindreq(p->fd, 1620, ebuf) < 0 ||
 261            dlbindack(p->fd, (char *)buf, ebuf) < 0)
 262             goto bad;
 263 #endif
 264
 265 I picked the number 1620 out of thin air.  The second parameter
 266 to dlbindreq() sets the value of dl_sap.  This dl_sap
 267 value is then passed along to the DLPI driver through
 268 the DL_BIND_REQ primitive.  I guess that it cannot be 0 under
 269 AIX, but I'm not sure.
 270
 271 If someone knows anything about DLPI, I'd appreciate a clarification.
 272 Basically, I am just using the DLPI specification at:
 273 http://www.opengroup.org/onlinepubs/009638599/ which is pretty good.
 274 The AIX documentation is not so well written.
 275
 276 But basically, after I fixed up pcap-dlpi.c, I managed to get libpcap
 277 working under AIX.  This enabled me to successfully run Ethereal,
 278 ie. all the packets on my Ethernet network correctly showed up
 279 as Ethernet and not Token Ring in the Ethereal screen.
 280
 281 YAY!
 282 --
 283 Craig Rodrigues
 284 http://www.gis.net/~craigr
 285 rodrigc@mediaone.net
 286
 287 Date: Thu, 11 Nov 1999 23:47:02 -0500
 288 From: Craig Rodrigues <rodrigc@mediaone.net>
 289 To: ethereal-dev@zing.org
 290 Subject: Re: [ethereal-dev] AIX: gtk problem solved, now an ethereal  problem
 291
 292 On Thu, Nov 11, 1999 at 11:50:23AM -0800, Guy Harris wrote:
 293 > > The only differences between gtkclist.c in the gtk distribution and
 294 > > gtkclist.c in the ethereal distribution relate to the ROW_ELEMENT
 295 > > macro.  It looks like an optimization for retrieving the GList item
 296 > > when the requested row is the last row in the list.
 297 >
 298 > Yup - as per my other mail, Ethereal does that rather a lot when
 299 > building the CList, and the optimization changes quadratic behavior to
 300 > linear behavior.
 301 >
 302 > > Any ideas why this causes trouble?
 303 >
 304 > Mismatches between the layouts of data structures as declared in the
 305 > "gtk/gtk*.h" files in the Ethereal source tree and the layouts as
 306 > declared in the header files in the GTK+ source (either due to header
 307 > file differences - although the header files appear to be identical to
 308 > the GTK+ 1.2.6 ones - or due to compiler behavior differences)?
 309
 310 I tried stepping things through the debugger, and constantly
 311 hit the same segfault inside gdk_string_width(), line 308 of gdkfont.c
 312
 313 Fails on line: switch(font->type),
 314 where *font is: (type = -1, ascent = -1, descent = -1)
 315
 316 Stack trace:
 317 gdk_string_width(font = 0x7caf01a4, string = "../"), line 308 in "gdkfont.c"
 318 gtk_file_selection_populate(fs = 0x20094468, rel_path = "", try_complete = 0), line 1341 in "gtkfilesel.c"
 319 gtk_file_selection_init(filesel = 0x20094468), line 513 in "gtkfilesel.c"
 320 gtk_type_new(0xc315), line 403 in "gtktypeutils.c"
 321 gtk_file_selection_new(title = "Ethereal: Open Capture File"), line 524 in "gtkfilesel.c"
 322 file_open_cmd_cb(0x200640f4, 0x0), line 79 in "file_dlg.c"
 323
 324 Removing gtkclist.o from libui.a and recompiling removed this problem.
 325
 326 Any ideas?  I'm stumped.
 327
 328 --
 329 Craig Rodrigues
 330 http://www.gis.net/~craigr
 331 rodrigc@mediaone.net