WebSVN – nexmon – Blame – Rev 1 – /utilities/wireshark/README.aix

1

office

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

--with-pcap=dlpi

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:

>

>

> Hmm.

>

> 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:

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

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

Hi,

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.

Any ideas?

Thanks.

--

Craig Rodrigues

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

***************

*** 795,809 ****

fi

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

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

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

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.

Any ideas?

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

Hi,

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:

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:

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)

goto bad;

#endif

I changed it to:

#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)

goto bad;

#endif

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.

YAY!

--

Craig Rodrigues

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.

--

Craig Rodrigues

http://www.gis.net/~craigr

340

rodrigc@mediaone.net

nexmon – Blame information for rev 1