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