README.aix

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