README.aix

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