Use *, not *.*, as the wildcard pattern on UN*X.
[metze/wireshark/wip.git] / 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