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