toasters

toasters@lists.teaparty.net

13515 discussions

Problems integrating CIFS and NFS access control
by Paul Lupa 17 Mar '00

17 Mar '00

Hi Folks, I have a problem with the operation of a NetApp that servers up a share both via CIFS and NFS. The goal of a group that I support was to have a common directory for both the UNIX systems and the NT systems. A user would be able to see all of their files under either UNIX or NT. The problem manifests itself because whatever was last used by the user to set access rights is what sets the security mode for the file or directory. For example, if a user accesses a directory from NT and gives himself and a NT group access to a file, from UNIX only he would have access. If from Unix he set a directory to rwxr-x---, someone in an NT group that he specifically want to grant access to would not have access. Generally speaking whatever was last used (NT or Unix) to set permissions works correctly, and the other one works, but not correctly. My questions to the group: 1: Is anyone sharing the same directory under CIFS and NFS and found a workaround or an acceptable way to implement permissions? 2: Has anyone thought about what would be wrong with using UNIX permissions to determine access when using NFS and NT permissions when using CIFS? Thanks, Paul Lupa

3 2

RE: Problems integrating CIFS and NFS access control
by Muhlestein, Mark 17 Mar '00

17 Mar '00

If you have a need for UNIX users to access files with ACLs it is not necessary for all UNIX users to have a unique NT account. You can use the "wafl.default_nt_user" to supply a default mapping. Or you can create a default mapping in the /etc/usermap.cfg file. This is all assuming 5.3 or later ONTAP, of course. Anyone using multiprotocol security on a filer should definitely consider an upgrade to a 5.3x release ASAP, since things work so much better. In particular, NFS access to files with ACLs is extremely limited in pre-5.3 releases. Mark Muhlestein -- mmm(a)netapp.com -----Original Message----- From: ZANGA, Michael, GCM [mailto:Michael.Zanga@gcm.com] Sent: Friday, March 17, 2000 5:38 AM To: 'Paul Lupa'; toasters(a)mathworks.com Subject: RE: Problems integrating CIFS and NFS access control What kind of security mode is the volume in question? Mixed mode can be problematic as NT rights supersede the Unix rights and basically lock a Unix user out THAT doesnt have a equivalent NT id. I would recommend using id that match on both side and not use mixed mode. I have a 200 gb volume with mixed clients and mixed mode was a problem at first. We changed the security style to Unix and all is well. -----Original Message----- From: Paul Lupa [mailto:Paul.Lupa@motorola.com] Sent: Friday, March 17, 2000 12:24 AM To: toasters(a)mathworks.com Subject: Problems integrating CIFS and NFS access control Hi Folks, I have a problem with the operation of a NetApp that servers up a share both via CIFS and NFS. The goal of a group that I support was to have a common directory for both the UNIX systems and the NT systems. A user would be able to see all of their files under either UNIX or NT. The problem manifests itself because whatever was last used by the user to set access rights is what sets the security mode for the file or directory. For example, if a user accesses a directory from NT and gives himself and a NT group access to a file, from UNIX only he would have access. If from Unix he set a directory to rwxr-x---, someone in an NT group that he specifically want to grant access to would not have access. Generally speaking whatever was last used (NT or Unix) to set permissions works correctly, and the other one works, but not correctly. My questions to the group: 1: Is anyone sharing the same directory under CIFS and NFS and found a workaround or an acceptable way to implement permissions? 2: Has anyone thought about what would be wrong with using UNIX permissions to determine access when using NFS and NT permissions when using CIFS? Thanks, Paul Lupa ********************************************************************** This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. ************************************************************************

1 0

RE: Problems integrating CIFS and NFS access control
by Muhlestein, Mark 17 Mar '00

17 Mar '00

On your "root" problem: is your NT user by chance a member of BUILTIN\Administrators? If so, you may want to turn off the "wafl.nt_admin_priv_map_to_root" option. (Of course, if you do that you should make sure that you still have an administrative account mapped to "root" that you can use). See http://now.netapp.com/NOW/knowledge/docs/olio/guides/53_troubleshooting/faq. shtml#anchor1392387 (Why is the UNIX owner of files I create set to "root"?) As to the problems you had using mixed qtrees, feedback on this would be very very valuable. We have found mixed mode to be quite usable, once people understand how to put it to best use. In general, please let us know when you have problems so we can address them, either in documentation or by changing the functionality. Mark Muhlestein -- mmm(a)netapp.com -----Original Message----- From: johnj.sasso(a)ps.ge.com [mailto:johnj.sasso@ps.ge.com] Sent: Friday, March 17, 2000 4:48 AM To: Paul.Lupa(a)motorola.com; toasters(a)mathworks.com Subject: RE: Problems integrating CIFS and NFS access control The area that the NT and UNIX users access on the NetApp, is that a MIXED-style qtree (as opposed to an NTFS- or UNIX-style qtree)? I had many problems using MIXED-style qtrees between UNIX and NT, with the behavior being inconsistent and confusing. I ended up using a UNIX-style qtree instead, sacrificing the NT ACLs the NTFS-style qtree offers. On that note, my login name for both UNIX and NT is identical. However, when I modify and save a file via NT (e.g. through Excel, Word) in a UNIX-style qtree, the file gets saved as root, thereby preventing me from accessing the file via UNIX. Very, very annoying. --john -----Original Message----- From: Paul Lupa [mailto:Paul.Lupa@motorola.com] Sent: Friday, March 17, 2000 12:24 AM To: toasters(a)mathworks.com Subject: Problems integrating CIFS and NFS access control Hi Folks, I have a problem with the operation of a NetApp that servers up a share both via CIFS and NFS. The goal of a group that I support was to have a common directory for both the UNIX systems and the NT systems. A user would be able to see all of their files under either UNIX or NT. The problem manifests itself because whatever was last used by the user to set access rights is what sets the security mode for the file or directory. For example, if a user accesses a directory from NT and gives himself and a NT group access to a file, from UNIX only he would have access. If from Unix he set a directory to rwxr-x---, someone in an NT group that he specifically want to grant access to would not have access. Generally speaking whatever was last used (NT or Unix) to set permissions works correctly, and the other one works, but not correctly. My questions to the group: 1: Is anyone sharing the same directory under CIFS and NFS and found a workaround or an acceptable way to implement permissions? 2: Has anyone thought about what would be wrong with using UNIX permissions to determine access when using NFS and NT permissions when using CIFS? Thanks, Paul Lupa

1 0

RE: Problems integrating CIFS and NFS access control
by Muhlestein, Mark 17 Mar '00

17 Mar '00

Make sure you are running 5.3 or greater. Once you are, determining access is pretty straightforward: * If the file has an NT ACL, the ACL is used to check permissions. NFS requests use the mapped NT identity of the requesting user. * If the file does not have an ACL, UNIX permissions are used. CIFS users use the mapped UNIX identity of the requesting user. In-house at NetApp we use the mixed mode a lot, because it gives the most flexibility. There is a web site on NOW than explains all about how to use the multi-protocol security on the filer: http://now.netapp.com/knowledge/docs/olio/guides/53_troubleshooting/index.sh tml About your suggestion about having the access check based on the client type: we considered that approach but we decided it results in even more confusing behavior as seen by non-native clients, as well as being less secure. The motivation for our approach is in the "Basic Concepts" section of the above document. If you still have questions, or you can't make your environment work the way you want it to, please let us know. Multi-protocol security can be confusing, but we are very interested in making it work as well as possible in as many situations as possible. Mark Muhlestein -- mmm(a)netapp.com -----Original Message----- From: Paul Lupa [mailto:Paul.Lupa@motorola.com] Sent: Thursday, March 16, 2000 9:24 PM To: toasters(a)mathworks.com Subject: Problems integrating CIFS and NFS access control Hi Folks, I have a problem with the operation of a NetApp that servers up a share both via CIFS and NFS. The goal of a group that I support was to have a common directory for both the UNIX systems and the NT systems. A user would be able to see all of their files under either UNIX or NT. The problem manifests itself because whatever was last used by the user to set access rights is what sets the security mode for the file or directory. For example, if a user accesses a directory from NT and gives himself and a NT group access to a file, from UNIX only he would have access. If from Unix he set a directory to rwxr-x---, someone in an NT group that he specifically want to grant access to would not have access. Generally speaking whatever was last used (NT or Unix) to set permissions works correctly, and the other one works, but not correctly. My questions to the group: 1: Is anyone sharing the same directory under CIFS and NFS and found a workaround or an acceptable way to implement permissions? 2: Has anyone thought about what would be wrong with using UNIX permissions to determine access when using NFS and NT permissions when using CIFS? Thanks, Paul Lupa

1 0

RE: Problems integrating CIFS and NFS access control
by ZANGA, Michael, GCM 17 Mar '00

17 Mar '00

What kind of security mode is the volume in question? Mixed mode can be problematic as NT rights supersede the Unix rights and basically lock a Unix user out THAT doesnt have a equivalent NT id. I would recommend using id that match on both side and not use mixed mode. I have a 200 gb volume with mixed clients and mixed mode was a problem at first. We changed the security style to Unix and all is well. -----Original Message----- From: Paul Lupa [mailto:Paul.Lupa@motorola.com] Sent: Friday, March 17, 2000 12:24 AM To: toasters(a)mathworks.com Subject: Problems integrating CIFS and NFS access control Hi Folks, I have a problem with the operation of a NetApp that servers up a share both via CIFS and NFS. The goal of a group that I support was to have a common directory for both the UNIX systems and the NT systems. A user would be able to see all of their files under either UNIX or NT. The problem manifests itself because whatever was last used by the user to set access rights is what sets the security mode for the file or directory. For example, if a user accesses a directory from NT and gives himself and a NT group access to a file, from UNIX only he would have access. If from Unix he set a directory to rwxr-x---, someone in an NT group that he specifically want to grant access to would not have access. Generally speaking whatever was last used (NT or Unix) to set permissions works correctly, and the other one works, but not correctly. My questions to the group: 1: Is anyone sharing the same directory under CIFS and NFS and found a workaround or an acceptable way to implement permissions? 2: Has anyone thought about what would be wrong with using UNIX permissions to determine access when using NFS and NT permissions when using CIFS? Thanks, Paul Lupa ********************************************************************** This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. ************************************************************************

1 0

RE: Problems integrating CIFS and NFS access control
by johnj.sasso＠ps.ge.com 17 Mar '00

17 Mar '00

The area that the NT and UNIX users access on the NetApp, is that a MIXED-style qtree (as opposed to an NTFS- or UNIX-style qtree)? I had many problems using MIXED-style qtrees between UNIX and NT, with the behavior being inconsistent and confusing. I ended up using a UNIX-style qtree instead, sacrificing the NT ACLs the NTFS-style qtree offers. On that note, my login name for both UNIX and NT is identical. However, when I modify and save a file via NT (e.g. through Excel, Word) in a UNIX-style qtree, the file gets saved as root, thereby preventing me from accessing the file via UNIX. Very, very annoying. --john -----Original Message----- From: Paul Lupa [mailto:Paul.Lupa@motorola.com] Sent: Friday, March 17, 2000 12:24 AM To: toasters(a)mathworks.com Subject: Problems integrating CIFS and NFS access control Hi Folks, I have a problem with the operation of a NetApp that servers up a share both via CIFS and NFS. The goal of a group that I support was to have a common directory for both the UNIX systems and the NT systems. A user would be able to see all of their files under either UNIX or NT. The problem manifests itself because whatever was last used by the user to set access rights is what sets the security mode for the file or directory. For example, if a user accesses a directory from NT and gives himself and a NT group access to a file, from UNIX only he would have access. If from Unix he set a directory to rwxr-x---, someone in an NT group that he specifically want to grant access to would not have access. Generally speaking whatever was last used (NT or Unix) to set permissions works correctly, and the other one works, but not correctly. My questions to the group: 1: Is anyone sharing the same directory under CIFS and NFS and found a workaround or an acceptable way to implement permissions? 2: Has anyone thought about what would be wrong with using UNIX permissions to determine access when using NFS and NT permissions when using CIFS? Thanks, Paul Lupa

1 0

RE: Help with vif's
by johnj.sasso＠ps.ge.com 16 Mar '00

16 Mar '00

The latest version of DataONTAP, 5.3.5, mentioned something about doing load-balancing across the links of a VIF. I have not delved into it any further, but can a NetApp person tell me if the new version indeed does load balancing across the VIF links (of course, on sending data from the NetApp to the client)? --john -----Original Message----- From: Michael S. Keller [mailto:mkeller@mail.wcg.net] Sent: Thursday, March 16, 2000 11:01 AM To: toasters(a)mathworks.com Subject: Re: Help with vif's Arthur Darren Dunham wrote: > > have the Catalyst set up properly. Can someone out there who's done > > this before tell me what we need to do on the cat? > > Do I need to put the vif commands into the rc file? > > Thanks in advance, > > The cisco (unless they've changed something recently) has a limitation > on how it sends packets across the links. Packets destined for the > truck will be hashed onto a link by the last two bits of the hardware > source address. That means if most of your traffic is coming from a > single router port, it's all going to get hashed down to only one link. The answer I received from NetApp, with a similar situation, was that the switch XORs the last two bits of source and destination MAC addresses, then uses that to choose the outgoing port within an EtherChannel trunk. With only four clients making heavy use of the VIFs, MACs clustered. With hundreds of clients, you should see a more even distribution. I built a truth table that showed then-current and desired states, then altered client MAC addresses. Does that answer the question? -- Michael S. Keller, Technical Solutions Consultant, Sprint Enterprise Network Services On loan to Williams Communications Group Voice 918-574-6094, Amateur Radio N5RDV

1 0

Re: NetApp backup recommendations
by Steve Kappel 16 Mar '00

16 Mar '00

>> NetBackup (Veritas) can only dump to tape drives connected directly to an >> NDMP server (i.e. only to a locally-attached NetApp drive, or to a remote >> NetApp with attached tape). It cannot do NDMP backups to a "normal" >> NetBackup media server. I've been told that NetBackup can only restore >> NDMP dumps in place, too -- not to an alternate directory, for example >> (I haven't verified that with the vendor). >> >Hmm this could be deadly for us. Legato recommends direct attached >tape drives which I was preferring and it makes sense for performance. Directly attached drives are more efficient. Even with plenty of network bandwidth, backing up over the network still puts a significant CPU load on the boxes. If the filers are physically within reach, a large library can have some of its drives split off onto separate SCSI buses and one bus attached to each filer. "normal" NetBackup media servers can also have some of the drives. Robotic control can be anywhere in such a config. This is really the best of all worlds (IMHO) as you get direct attach performance on all boxes but you are sharing the library. If they are not physically within reach then 3-way backup to another filer can be used. Large sites may dedicate a NetApp as a "tape server". I believe there are library vendors that are looking at supporting NDMP directly in their libraries. >But we got discussing this issue, and the idea of the NetApp >spontaneously rebooting due to a SCSI bus error (from the tape drive) >came up. For our new NetApp we cannot afford to have this happen. >It's not so critical for our existing filer. Our existing filer runs >OnTap 5.2.1 and has rebooted once (in approx 7 months) due to a SCSI >bus error (a tape got stuck in the jukebox and the filer booted to >try to clear the error). Although with newer revs of OnTap and the >firmware, maybe this isn't an issue any more? I have never seen this with the NetApp's we have in NetBackup development. I see plenty of bus resets but never a reboot. __________________________________________________________________________ Steve Kappel steve.kappel(a)veritas.com VERITAS Software steve.kappel(a)iname.com (Personal)

1 0

Subscription
by Donna Spitz 16 Mar '00

16 Mar '00

Hello, I would like to subscribe to your group: Donna Spitz DonnaS(a)Worksta.com Thank you for your help. Donna

1 0

DLT recommendations
by Ethan Torretta 15 Mar '00

15 Mar '00

I need to buy a DLT device to backup a single F760 in an IS environment. The DLT7000 devices I've found, though, are single-ended. Does anyone have a favorite DLT7000 differential single- or multi-tape device? I've seen people have good luck with minilibraries, but that's an unnecessary expense in this case. I'm also curious about the DLT8000, as I'm buying a new drive anyway. Can they be set to be compatible with a filer? ejt

3 2

NetApp Reseller
by TTSG 15 Mar '00

15 Mar '00

Hi, Can anyone suggest a good NetApp reseller? (In the North East is extra points, able to ship to Germany for even more extra points) (New or used) Also, wondering what the general availability/delivery of one is... Private replies please. Tuc/TTSG

1 0

RE: Incremental backup of snapshots
by Anders Ljungberg S (QDT) 15 Mar '00

15 Mar '00

Hi! I think your problem is the way Legato is handling archive bits in NT. On the readonly snapshot area archive bits cant be reseted. On the NT frontend set the variable NSR_AVIODE_ARCHIVE to YES ( i think ). This will take archive bits out of play and you'll be using mtime. Unfortunally NT is'nt always that consekvent about modifying mtime. Good Luck Anders Ljungberg -----Original Message----- From: Christopher Algar [mailto:christopher.algar@s1.com] Sent: Tuesday, March 14, 2000 5:02 PM To: toasters Subject: Incremental backup of snapshots Have a backup problem using Solstice backup 5.1.1 - Legato networker in drag. I'm backing up the ntfs qtrees of an F760 by adding \\filer\share\.snapshot\nightly.0 to the client save sets on an nt server running the solstice backup client. We have 3 qtrees backed up in this way, all within the same volume, ntfs security style and oplocks enabled. Share Qtree \\filer\home\.snapshot\nightly.0 vol0/home \\filer\fs04_bak\.snapshot\nightly.0 vol0/be01fs04 \\filer\fs02_bak\.snapshot vol0/be01fs02 All of them are copied to tape, but only home has incremental smaller than full backups. Any ideas what to check, or why one should work and not the others. Obviously this using a lot more taps and bandwidth than required. Thanks, Chris Algar

1 0

RE: Incremental backup of snapshots
by Muhlestein, Mark 14 Mar '00

14 Mar '00

Snapshots are read only. That means the backup app can't clear the DOS archive bit. It sounds like the solstice backup app is using the archive bit. If they were using the times on the files it would work. Incremental mode should work on the live filesystem. Mark Muhlestein -- mmm(a)netapp.com -----Original Message----- From: Christopher Algar [mailto:christopher.algar@s1.com] Sent: Tuesday, March 14, 2000 9:02 AM To: toasters Subject: Incremental backup of snapshots Have a backup problem using Solstice backup 5.1.1 - Legato networker in drag. I'm backing up the ntfs qtrees of an F760 by adding \\filer\share\.snapshot\nightly.0 to the client save sets on an nt server running the solstice backup client. We have 3 qtrees backed up in this way, all within the same volume, ntfs security style and oplocks enabled. Share Qtree \\filer\home\.snapshot\nightly.0 vol0/home \\filer\fs04_bak\.snapshot\nightly.0 vol0/be01fs04 \\filer\fs02_bak\.snapshot vol0/be01fs02 All of them are copied to tape, but only home has incremental smaller than full backups. Any ideas what to check, or why one should work and not the others. Obviously this using a lot more taps and bandwidth than required. Thanks, Chris Algar

1 0

Incremental backup of snapshots
by Christopher Algar 14 Mar '00

14 Mar '00

Have a backup problem using Solstice backup 5.1.1 - Legato networker in drag. I'm backing up the ntfs qtrees of an F760 by adding \\filer\share\.snapshot\nightly.0 to the client save sets on an nt server running the solstice backup client. We have 3 qtrees backed up in this way, all within the same volume, ntfs security style and oplocks enabled. Share Qtree \\filer\home\.snapshot\nightly.0 vol0/home \\filer\fs04_bak\.snapshot\nightly.0 vol0/be01fs04 \\filer\fs02_bak\.snapshot vol0/be01fs02 All of them are copied to tape, but only home has incremental smaller than full backups. Any ideas what to check, or why one should work and not the others. Obviously this using a lot more taps and bandwidth than required. Thanks, Chris Algar

1 0

SQL Server 7 and I/O error 59
by Jack Verdirame 14 Mar '00

14 Mar '00

Hello, We are running into an issue with the TCP/IP stack on an NT SQL Server machine over multi-gigabit ports. We have tried eliminating ports, reconfiguring and the error never seems to go away. We have not seemed to isolate the problem other then it seems to be the NT machine. We see no errors in the etc/messages and the interfaces seems to be running flawlessly (246 million packets and only 10 errors, 27 CRC's). We have seen only a few CP to CP but never when the problem occurs. We currently are simulating approx 20 - 40 meg of traffic over 2 gig cards using the test software that comes with SQL server 7. It is built on the traffic simulator and load generator IOMeter. The filer seems to be running great - 11,000 + ops per second without a problem. Any ideas or things to look for would be helpful. I have found some problems with NT and the net use command and found a service pack but it was for terminal server. The error was an I/O error 59 problem with tearing down multiple TCP sessions over UNC path mapped file transfers. Thanks for your time, Jack Verdirame www.zerowait.com www.loadbalancing.net Las Vegas: 302.559.5962 Corp: 302.266.9408

1 0

problem in .profile
by bhaskar.g＠philips.com 13 Mar '00

13 Mar '00

Hi, We started creating user accounts with their home folders on the filer 720. But the new users are unable to set the environment as they login. The problem is the terminal doesnot read the .profile in the home folder though .profile exists and the user owns it. But when we remsh to some other system or the same system the .profile is working. When the user logs in from the Xterm this problem occurs. Please let us know what is the problem. regards Bhaskar G Systems Engineer, Philips Semiconductors, #3, Sterling Square,Madras Bank Road, Off St Mark's Road,BANGALORE-560 001. Voice : +91 80 222 9200 Ext 5060 Fax: +91 80 2229700

2 1

None
by bhaskar.g＠philips.com 13 Mar '00

13 Mar '00

Hi all, Please can any one tell me how to solve the following problem. sunitha@detroit$ ll total 336 -rwxrwxr-x 1 sunitha WEB 1936 Jan 28 10:17 Glite_To_do27thJan.html -rwxrwxr-x 1 sunitha WEB 5945 Feb 11 16:49 Glite_to10Feb.html -rwxrwxr-x 1 sunitha WEB 20992 Mar 1 11:51 Glite_to24thFeb.xls -rwxrwxr-x 1 sunitha WEB 30068 Feb 28 17:48 estimation_back.html drwxrwxr-x 2 sunitha WEB 4096 Mar 7 14:42 images -rwxrwxr-x 1 sunitha WEB 690 Mar 2 16:52 index.html -rwxrwxr-x 1 sunitha WEB 418 Feb 5 16:03 innovteam.html -rwxrwxr-x 1 sunitha WEB 2466 Mar 7 14:45 right_innov.html sunitha@detroit$ cp -p right_innov.html /home/www/htdocs/groups/innov/. cp: utime failed right_innov.html: Not owner sunitha@detroit$ regards Bhaskar G Systems Engineer, Philips Semiconductors, #3, Sterling Square,Madras Bank Road, Off St Mark's Road,BANGALORE-560 001. Voice : +91 80 222 9200 Ext 5060 Fax: +91 80 2229700

1 0

Solaris NFSv3 read-ahead kernel parameter...
by Eyal Traitel 13 Mar '00

13 Mar '00

Have someone played with / checked / benchmarked with this setting in Solaris kernel ? I'm speaking about nfs3_nra .... Eyal.

2 1

Re: filter-side packet tracing.
by Guy Harris 11 Mar '00

11 Mar '00

To clear up some confusion, "captrans" isn't a "Solaris command" in the sense of something that comes with Solaris - it happens to be installed on the Solaris/SPARC machines inside NetApp, but it's in "/usr/local/bin", not "/usr/bin" or "/usr/sbin". It's built atop a version of libpcap modified to be able to read non-libpcap files as well as libpcap files. There's probably no reason why we couldn't make available captrans source and the changes to libpcap... ...but, as per my other message, I'm not really interested in captrans, or those changes to libpcap, any more - recent distributions of Ethereal: http://ethereal.zing.org/ comes with a better capture-conversion program, editcap, which reads and writes more capture file formats than captrans, and which has more people developing stuff for it than just me (and, as indicated, I'm not doing any more stuff with captrans or the modified libpcap; my capture file reader and writer efforts are directed towards the Wiretap library that Ethereal, Tethereal, and editcap use). So, whilst we *could* share those utilities, I'd rather people download Ethereal and build and install that instead; if anybody asks for new features in captrans, or new capture file types to read or write, or finds a bug in captrans or in the capture file reading code in the modified libpcap, I will probably check to see whether Wiretap and editcap do what they want and, if not, try to make them do so and point the asker at editcap instead. (Besides, as noted, if you download Ethereal and build and install it, you get, in addition to a capture-file-translation program, a really nice GUI packet capture and analysis program, and a really nice tty-based packet capture and analysis program, as a free bonus. :-))

1 0

Re: filer-side packet tracing.
by Jagan Bearelly 11 Mar '00

11 Mar '00

---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Charset: us-ascii X-Sun-Content-Lines: 156 Steve, Little correction, "captrans" is a NetApp tool, please follow recommendation from Guy Harris earlier today. Thank you. Regards, Jagan Bearelly >From guy(a)netapp.com Fri Mar 10 11:37:27 2000 From: Guy Harris <guy(a)netapp.com> Subject: Re: FW: filer-side packet tracing. To: "Uren, Jim" <jim.uren(a)netapp.com> Date: Fri, 10 Mar 2000 11:24:37 -0800 (PST) CC: armijo(a)cs.unm.edu, toasters(a)mathworks.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit > On Thu, Mar 09, 2000 at 03:18:52PM -0800, Fox, Adam wrote: > > > > Yes. pktt will do this. It creates a file in tcpdump format, > > which is convertable into snoop with the right utilities. > > would you folks(NetApp) be willing to share these utilities? As the author of captrans (the utility in question) and the changes to libpcap required to make it read other capture file formats, I don't have any problem making that stuff available. *However*, there's a better program than captrans - editcap. It's part of the Ethereal packet capture/analysis program package: http://ethereal.zing.org/ and uses the same library that Ethereal (and the text-mode - snoop/tcpdump-like - utility Tethereal that also comes with Ethereal) uses to read and write capture files. That library can read more capture file formats than can the patched libpcap I have here, and can also write more formats than can captrans. I don't plan to add any new capture file formats to the patched libpcap, but there are many people who have added new formats to the Wiretap library in Ethereal, and we will probably continue to add new formats as they come up (and as we can figure them out - a lot of the formats were figured out by reverse-engineering, as no documentation was available). Ethereal requires GLib 1.2[.x] and GTK+ 1.2[.x], so you'd have to have them installed on your system in order to build editcap (unless you tweak the Makefile by hand so as to build only the Wiretap library and editcap, in which case you need only GLib 1.2[.x], but once you've installed GLib, you might as well install GTK+ while you're at it), but, once you've done that, you not only have a program to convert capture files, you have a pretty nice GUI packet capture and analysis program, and a pretty nice text-mode packet capture and analysis program as well. (It also runs on Win32 operating systems such as Windows 9x and Windows NT - you have to get versions of GLib, GTK+, and libpcap that have been ported to Win32, but those all exist, and Ethereal can even capture packets on Win32 OSes with that version of libpcap.) There's also, on the "Download" page of the Ethereal Web site, a list of links to binary packages that have been made of Ethereal - or, at least, links to archive sites for binary packages for various OSes - although there's no guarantee that the latest version of Ethereal has been so packaged, in which case the package might not include editcap or Tethereal. > From jagan(a)netapp.com Fri Mar 10 15:48:25 2000 > Date: Fri, 10 Mar 2000 15:48:17 -0800 (PST) > From: Jagan Bearelly <jagan(a)netapp.com> > To: jonas.jonsson(a)proact.se, armijo(a)cs.unm.edu, jagan(a)netapp.com > Subject: Re: filer-side packet tracing. > Cc: Adam.Fox(a)netapp.com, toasters(a)mathworks.com > > Steve, > > Here is a documentation on "pktt" too. Please see the attachment. > Thank you. > > Regards, > Jagan Bearelly > > > From jagan(a)netapp.com Fri Mar 10 15:43:26 2000 > > Date: Fri, 10 Mar 2000 15:23:56 -0800 (PST) > > From: Jagan Bearelly <jagan(a)netapp.com> > > To: jonas.jonsson(a)proact.se, armijo(a)cs.unm.edu > > Subject: Re: filer-side packet tracing. > > Cc: Adam.Fox(a)netapp.com, toasters(a)mathworks.com > > > > > > Steve, > > > > The solaris command "captrans" can be used for conversion and > > Solaris has man pages for this command. For example, to convert > > pktt trace file called "e0.trc" into a snoop format, the following > > command works on Solaris: > > > > captrans -f snoop e0.trc > e0.trc.snoop > > > > Please let me know if you need man pages for "captrans". > > I hope that helps. > > > > Regards, > > Jagan > > > > > From armijo(a)cs.unm.edu Fri Mar 10 15:07:59 2000 > > > Date: Fri, 10 Mar 2000 15:59:35 -0700 > > > From: Steve Armijo <armijo(a)cs.unm.edu> > > > To: Jonas Jonsson <jonas.jonsson(a)proact.se> > > > Cc: "'Steve Armijo'" <armijo(a)cs.unm.edu>, "Fox, Adam" <Adam.Fox(a)netapp.com>, > > > toasters(a)mathworks.com > > > Subject: Re: filer-side packet tracing. > > > Mime-Version: 1.0 > > > > > > On Fri, Mar 10, 2000 at 11:59:30AM +0100, Jonas Jonsson wrote: > > > > > > > > Well, > > > > > > > > In netcache v4.1 there is a presentation of this so it > > > > is somewhat documented. > > > > > > > > I can't say that I know the documentation of the filer side as > > > > well ;) > > > > > > > > > -----Original Message----- > > > > > From: Steve Armijo [mailto:armijo@cs.unm.edu] > > > > > Sent: den 10 mars 2000 10:34 > > > > > To: Fox, Adam > > > > > Cc: 'Ronan Mullally'; toasters(a)mathworks.com > > > > > Subject: Re: filer-side packet tracing. > > > > > > > > > > > > > > > On Thu, Mar 09, 2000 at 03:18:52PM -0800, Fox, Adam wrote: > > > > > > > > > > > > Yes. pktt will do this. It creates a file in tcpdump format, > > > > > > which is convertable into snoop with the right utilities. > > > > > > > > > > would you folks(NetApp) be willing to share these utilities? > > > > > > ok, i guess i should have been more specific. would you be willing to > > > share the conversion utilities? > > > > > > -s > > > > > > -- > > > Cue the music, fade to black, no such thing as no payback. -PWEI > > > > > > [ armijo(a)cs.unm.edu ] > > > > > > > > ---------- X-Sun-Data-Type: default X-Sun-Data-Name: pktt_doc X-Sun-Charset: us-ascii X-Sun-Content-Lines: 225 Packet trace facility With the increased use of fast, switched networks it is becoming harder to get network traces from customers. Yet frequently that is the only way to debug certain problems. For that reason we have added a primitive facility for capturing network traffic on the filer, since it is the one place which has access to all network data. There are two main uses. If a customer site is experiencing crashing bugs it is often useful to have a trace of recent network activity, because the crash is frequently caused by an incoming request. It is possible to log packet traces to memory, where they can then be extracted from the core file. Since the filer is a storage device, it is also possible to save the packet traces on disk. This can be used to diagnose connectivity problems or unexpected requests, particularly for CIFS where the application/redirector/network combination may make it difficult or impossible to recreate the customer situation. Command usage The new command is "pktt" and it is invoked as follows: pktt start <if>|all [-d dir] [-s size] [-m pklen] [-b bsize] [-i ipaddr ...] [-v] pktt pause <if>|all pktt dump <if>|all [-d dir] pktt stop <if>|all pktt status [<if>|all] [-v] Each of the subcommands must be followed by an interface name or the word "all." A small exception to this is that "pktt status -v" is equivalent to "pktt status all -v". The available interface names can be found via "ifconfig -a" or "pktt status." pktt start The "start" subcommand is used to start tracing, (or restart if it has been paused). The packet trace data is stored in "tcpdump" format in a circular buffer in memory. The flags that can optionally be supplied are as follows: -d dir This specifies the path to an existing directory in which the trace data file will be written. The file will always have the name "<if>.trc" where "<if>" is the interface name (e.g. e4, fa3, etc.). If this option is missing the trace data will only be collected in memory, and after the buffer fills, new packets will replace existing packets. However, it is always possible to dump the contents of the buffer at any time using the "pktt dump" command. One thing to be aware of when writing trace data to disk is that if the filesystem cannot keep up with the network traffic you may not log all packets. This will show up in the "dropped" counts when looking at status. Along with this, you should remember that logging all traffic may generate a heavy write load on the filer which may bog it down. If possible, use the IP filter to reduce the amount of data to log. Note that the default value of the -b flag is too small when logging to disk if there is much traffic. You should set -b 128k or larger. (But not too large! See below.) -s size This allows you to set a maximum size of the trace file. If you don't specify this the file can grow to 32GB, so you should be careful to set it to a reasonable value if you think there is a chance you might forget you have left the trace going. This parameter is only useful in conjunction with the "-d" option. After the maximum size has been reached, packets continue to be logged to the buffer, but not to disk. -m pklen This sets the length at which packets will be truncated. The default is 1500 bytes, which results in full packets for ethernet. Note that in 5.3 the default of 1500 is incorrect for ethernet. You must override with "-m 1514" to get the full packets. It is sometimes useful to limit the data stored when every byte of the packet is not critical. However, for many debugging tasks it is useful to have the entire packet. In the case where the packet size can be larger than 1500 you may want to specify a larger maximum. However, many of the decoders refuse to deal with packets larger than 1500 bytes so you should only specify a larger value if that seems critical to finding the problem. -b bsize This sets the buffer size, which may be specified as a number with an optional trailing 'k' or 'm' multiplier. The default is 32K, which is fairly small but may be OK for finding "packet of death" bugs and the like. You should use a value of at least 128K when using the -d option. The value may range from 8K to 128M, but only in the most exceptional cases would it be necessary to increase the size beyond 1-2M. In cases where the network is very busy and it is not practical to log all the traffic to disk you may need to use a larger buffer. Warning! Do not specify a value larger than 3MB, even on a 1GB 760 filer! You may hang the system console or cause WAFL to run out of memory. This will be enforced in later versions, but in 5.3 you have to be careful not to specify too large a buffer size. -i ipaddr [-i ipaddr] ... This allows a kind of primitive filtering capability. Up to four IP address may be specified, which causes only traffic to or from any of those IP addresses to be logged. This will, of course, prevent logging of any non-IP (e.g. arp/rarp) traffic. -v This causes "pktt status -v" information to be displayed as tracing starts. Examples of "pktt start" pktt start e0 This will start capturing network traffic from the "e0" interface. All traffic will be logged to a 32K circular buffer. Or, if tracing had been suspended previously it would be restarted. pktt start fa3 -d / -s 100m -b 128k This starts capturing traffic on the "fa3" interface, writing to a file called "/fa3.trc" which will be allowed to grow to a maximum size of 100MB, with a 128K buffer. pktt start el10 -d /home -m 10k -b 1m -i ehost1 -i ehost2 This starts capturing traffic to and from the hosts "ehost1" and "ehost2", storing the traces into the file "/home/el10.trc". Up to 10K of each packets will be stored, in a 1MB buffer. pktt start all -b 128k -i 172.20.4.1 All interfaces will start capturing traffic to and from the specified IP address. This is a quick way to look at traffic if you're not sure which interface to use but you want to see the packets from one or more IP addresses. pktt pause The "pause" subcommand is used to temporarily stop capturing traffic from one or all interfaces. If any unwritten data is in the trace buffer it will be flushed to disk. Use "pktt start" without any options to restart a paused interface. pktt dump The "dump" subcommand causes the contents of the packet trace buffer to be written to a file. If the "-d <dir>" option is used the file will be written to that directory, otherwise it will be written to the root directory of the root volume. The name of the file is always <if>.trc, and the contents are in "tcpdump" format. If a file by that name already exists it will be overwritten. pktt stop This causes all tracing to stop on the named interface, or all interfaces. If any unwritten data is in the trace buffer it will be flushed to disk. If you have not dumped the trace data and you were not tracing to a disk file, the trace data will be lost. This action is not confirmed, so be careful when using this command. pktt status This can be used to display the buffer and file status of an existing trace. Using "pktt status -v" will give you full tracing status for all interfaces. Using pktt with "captrans" and "tcpslice" Guy Harris' "captrans" program is your friend. It allows you to convert between "tcpdump" format and "snoop," "netmon," or "sniffer" formats so that you can use your favorite packet parser to look at the traffic. For example, tooting> captrans -f snoop /n/filer/root/e4.trc > ~/mycap.snoop tooting> snoop -i ~/mycap.snoop | more See the captrans man page for more details on how to use it. Another useful program is "tcpslice," which can be used to extract time slices from trace files. Unfortunately it won't merge trace files from multiple interfaces. Someday we should enhance it to do that, since it frequently happens that traffic for one client appears on multiple interfaces.

1 0

Re: filer-side packet tracing.
by Jagan Bearelly 10 Mar '00

10 Mar '00

---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Charset: us-ascii X-Sun-Content-Lines: 77 Steve, Here is a documentation on "pktt" too. Please see the attachment. Thank you. Regards, Jagan Bearelly > From jagan(a)netapp.com Fri Mar 10 15:43:26 2000 > Date: Fri, 10 Mar 2000 15:23:56 -0800 (PST) > From: Jagan Bearelly <jagan(a)netapp.com> > To: jonas.jonsson(a)proact.se, armijo(a)cs.unm.edu > Subject: Re: filer-side packet tracing. > Cc: Adam.Fox(a)netapp.com, toasters(a)mathworks.com > > > Steve, > > The solaris command "captrans" can be used for conversion and > Solaris has man pages for this command. For example, to convert > pktt trace file called "e0.trc" into a snoop format, the following > command works on Solaris: > > captrans -f snoop e0.trc > e0.trc.snoop > > Please let me know if you need man pages for "captrans". > I hope that helps. > > Regards, > Jagan > > > From armijo(a)cs.unm.edu Fri Mar 10 15:07:59 2000 > > Date: Fri, 10 Mar 2000 15:59:35 -0700 > > From: Steve Armijo <armijo(a)cs.unm.edu> > > To: Jonas Jonsson <jonas.jonsson(a)proact.se> > > Cc: "'Steve Armijo'" <armijo(a)cs.unm.edu>, "Fox, Adam" <Adam.Fox(a)netapp.com>, > > toasters(a)mathworks.com > > Subject: Re: filer-side packet tracing. > > Mime-Version: 1.0 > > > > On Fri, Mar 10, 2000 at 11:59:30AM +0100, Jonas Jonsson wrote: > > > > > > Well, > > > > > > In netcache v4.1 there is a presentation of this so it > > > is somewhat documented. > > > > > > I can't say that I know the documentation of the filer side as > > > well ;) > > > > > > > -----Original Message----- > > > > From: Steve Armijo [mailto:armijo@cs.unm.edu] > > > > Sent: den 10 mars 2000 10:34 > > > > To: Fox, Adam > > > > Cc: 'Ronan Mullally'; toasters(a)mathworks.com > > > > Subject: Re: filer-side packet tracing. > > > > > > > > > > > > On Thu, Mar 09, 2000 at 03:18:52PM -0800, Fox, Adam wrote: > > > > > > > > > > Yes. pktt will do this. It creates a file in tcpdump format, > > > > > which is convertable into snoop with the right utilities. > > > > > > > > would you folks(NetApp) be willing to share these utilities? > > > > ok, i guess i should have been more specific. would you be willing to > > share the conversion utilities? > > > > -s > > > > -- > > Cue the music, fade to black, no such thing as no payback. -PWEI > > > > [ armijo(a)cs.unm.edu ] > > > > > ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: pktt_doc X-Sun-Charset: us-ascii X-Sun-Content-Lines: 225 Packet trace facility With the increased use of fast, switched networks it is becoming harder to get network traces from customers. Yet frequently that is the only way to debug certain problems. For that reason we have added a primitive facility for capturing network traffic on the filer, since it is the one place which has access to all network data. There are two main uses. If a customer site is experiencing crashing bugs it is often useful to have a trace of recent network activity, because the crash is frequently caused by an incoming request. It is possible to log packet traces to memory, where they can then be extracted from the core file. Since the filer is a storage device, it is also possible to save the packet traces on disk. This can be used to diagnose connectivity problems or unexpected requests, particularly for CIFS where the application/redirector/network combination may make it difficult or impossible to recreate the customer situation. Command usage The new command is "pktt" and it is invoked as follows: pktt start <if>|all [-d dir] [-s size] [-m pklen] [-b bsize] [-i ipaddr ...] [-v] pktt pause <if>|all pktt dump <if>|all [-d dir] pktt stop <if>|all pktt status [<if>|all] [-v] Each of the subcommands must be followed by an interface name or the word "all." A small exception to this is that "pktt status -v" is equivalent to "pktt status all -v". The available interface names can be found via "ifconfig -a" or "pktt status." pktt start The "start" subcommand is used to start tracing, (or restart if it has been paused). The packet trace data is stored in "tcpdump" format in a circular buffer in memory. The flags that can optionally be supplied are as follows: -d dir This specifies the path to an existing directory in which the trace data file will be written. The file will always have the name "<if>.trc" where "<if>" is the interface name (e.g. e4, fa3, etc.). If this option is missing the trace data will only be collected in memory, and after the buffer fills, new packets will replace existing packets. However, it is always possible to dump the contents of the buffer at any time using the "pktt dump" command. One thing to be aware of when writing trace data to disk is that if the filesystem cannot keep up with the network traffic you may not log all packets. This will show up in the "dropped" counts when looking at status. Along with this, you should remember that logging all traffic may generate a heavy write load on the filer which may bog it down. If possible, use the IP filter to reduce the amount of data to log. Note that the default value of the -b flag is too small when logging to disk if there is much traffic. You should set -b 128k or larger. (But not too large! See below.) -s size This allows you to set a maximum size of the trace file. If you don't specify this the file can grow to 32GB, so you should be careful to set it to a reasonable value if you think there is a chance you might forget you have left the trace going. This parameter is only useful in conjunction with the "-d" option. After the maximum size has been reached, packets continue to be logged to the buffer, but not to disk. -m pklen This sets the length at which packets will be truncated. The default is 1500 bytes, which results in full packets for ethernet. Note that in 5.3 the default of 1500 is incorrect for ethernet. You must override with "-m 1514" to get the full packets. It is sometimes useful to limit the data stored when every byte of the packet is not critical. However, for many debugging tasks it is useful to have the entire packet. In the case where the packet size can be larger than 1500 you may want to specify a larger maximum. However, many of the decoders refuse to deal with packets larger than 1500 bytes so you should only specify a larger value if that seems critical to finding the problem. -b bsize This sets the buffer size, which may be specified as a number with an optional trailing 'k' or 'm' multiplier. The default is 32K, which is fairly small but may be OK for finding "packet of death" bugs and the like. You should use a value of at least 128K when using the -d option. The value may range from 8K to 128M, but only in the most exceptional cases would it be necessary to increase the size beyond 1-2M. In cases where the network is very busy and it is not practical to log all the traffic to disk you may need to use a larger buffer. Warning! Do not specify a value larger than 3MB, even on a 1GB 760 filer! You may hang the system console or cause WAFL to run out of memory. This will be enforced in later versions, but in 5.3 you have to be careful not to specify too large a buffer size. -i ipaddr [-i ipaddr] ... This allows a kind of primitive filtering capability. Up to four IP address may be specified, which causes only traffic to or from any of those IP addresses to be logged. This will, of course, prevent logging of any non-IP (e.g. arp/rarp) traffic. -v This causes "pktt status -v" information to be displayed as tracing starts. Examples of "pktt start" pktt start e0 This will start capturing network traffic from the "e0" interface. All traffic will be logged to a 32K circular buffer. Or, if tracing had been suspended previously it would be restarted. pktt start fa3 -d / -s 100m -b 128k This starts capturing traffic on the "fa3" interface, writing to a file called "/fa3.trc" which will be allowed to grow to a maximum size of 100MB, with a 128K buffer. pktt start el10 -d /home -m 10k -b 1m -i ehost1 -i ehost2 This starts capturing traffic to and from the hosts "ehost1" and "ehost2", storing the traces into the file "/home/el10.trc". Up to 10K of each packets will be stored, in a 1MB buffer. pktt start all -b 128k -i 172.20.4.1 All interfaces will start capturing traffic to and from the specified IP address. This is a quick way to look at traffic if you're not sure which interface to use but you want to see the packets from one or more IP addresses. pktt pause The "pause" subcommand is used to temporarily stop capturing traffic from one or all interfaces. If any unwritten data is in the trace buffer it will be flushed to disk. Use "pktt start" without any options to restart a paused interface. pktt dump The "dump" subcommand causes the contents of the packet trace buffer to be written to a file. If the "-d <dir>" option is used the file will be written to that directory, otherwise it will be written to the root directory of the root volume. The name of the file is always <if>.trc, and the contents are in "tcpdump" format. If a file by that name already exists it will be overwritten. pktt stop This causes all tracing to stop on the named interface, or all interfaces. If any unwritten data is in the trace buffer it will be flushed to disk. If you have not dumped the trace data and you were not tracing to a disk file, the trace data will be lost. This action is not confirmed, so be careful when using this command. pktt status This can be used to display the buffer and file status of an existing trace. Using "pktt status -v" will give you full tracing status for all interfaces. Using pktt with "captrans" and "tcpslice" Guy Harris' "captrans" program is your friend. It allows you to convert between "tcpdump" format and "snoop," "netmon," or "sniffer" formats so that you can use your favorite packet parser to look at the traffic. For example, tooting> captrans -f snoop /n/filer/root/e4.trc > ~/mycap.snoop tooting> snoop -i ~/mycap.snoop | more See the captrans man page for more details on how to use it. Another useful program is "tcpslice," which can be used to extract time slices from trace files. Unfortunately it won't merge trace files from multiple interfaces. Someday we should enhance it to do that, since it frequently happens that traffic for one client appears on multiple interfaces.

1 0

Re: filer-side packet tracing.
by Jagan Bearelly 10 Mar '00

10 Mar '00

Steve, The solaris command "captrans" can be used for conversion and Solaris has man pages for this command. For example, to convert pktt trace file called "e0.trc" into a snoop format, the following command works on Solaris: captrans -f snoop e0.trc > e0.trc.snoop Please let me know if you need man pages for "captrans". I hope that helps. Regards, Jagan > From armijo(a)cs.unm.edu Fri Mar 10 15:07:59 2000 > Date: Fri, 10 Mar 2000 15:59:35 -0700 > From: Steve Armijo <armijo(a)cs.unm.edu> > To: Jonas Jonsson <jonas.jonsson(a)proact.se> > Cc: "'Steve Armijo'" <armijo(a)cs.unm.edu>, "Fox, Adam" <Adam.Fox(a)netapp.com>, > toasters(a)mathworks.com > Subject: Re: filer-side packet tracing. > Mime-Version: 1.0 > > On Fri, Mar 10, 2000 at 11:59:30AM +0100, Jonas Jonsson wrote: > > > > Well, > > > > In netcache v4.1 there is a presentation of this so it > > is somewhat documented. > > > > I can't say that I know the documentation of the filer side as > > well ;) > > > > > -----Original Message----- > > > From: Steve Armijo [mailto:armijo@cs.unm.edu] > > > Sent: den 10 mars 2000 10:34 > > > To: Fox, Adam > > > Cc: 'Ronan Mullally'; toasters(a)mathworks.com > > > Subject: Re: filer-side packet tracing. > > > > > > > > > On Thu, Mar 09, 2000 at 03:18:52PM -0800, Fox, Adam wrote: > > > > > > > > Yes. pktt will do this. It creates a file in tcpdump format, > > > > which is convertable into snoop with the right utilities. > > > > > > would you folks(NetApp) be willing to share these utilities? > > ok, i guess i should have been more specific. would you be willing to > share the conversion utilities? > > -s > > -- > Cue the music, fade to black, no such thing as no payback. -PWEI > > [ armijo(a)cs.unm.edu ] > >

1 0

RE: filer-side packet tracing.
by Jonas Jonsson 10 Mar '00

10 Mar '00

Well, In netcache v4.1 there is a presentation of this so it is somewhat documented. I can't say that I know the documentation of the filer side as well ;) /// Cheers, Jonas Performance, Simplicity, Network Necessity! NetCache! NetCache! PROVEN! FAST & FRESH! NetCache is Scaling the Internet! NetCache is Moving Content to the Edge! Speed! Control! Intelligence! NetCache! This email is cache friendly :) ---------------------------------------- > -----Original Message----- > From: Steve Armijo [mailto:armijo@cs.unm.edu] > Sent: den 10 mars 2000 10:34 > To: Fox, Adam > Cc: 'Ronan Mullally'; toasters(a)mathworks.com > Subject: Re: filer-side packet tracing. > > > On Thu, Mar 09, 2000 at 03:18:52PM -0800, Fox, Adam wrote: > > > > Yes. pktt will do this. It creates a file in tcpdump format, > > which is convertable into snoop with the right utilities. > > would you folks(NetApp) be willing to share these utilities? > > -s > > -- > Cue the music, fade to black, no such thing as no payback. -PWEI > > [ armijo(a)cs.unm.edu ] >

2 1

Re: FW: filer-side packet tracing.
by Guy Harris 10 Mar '00

10 Mar '00

> On Thu, Mar 09, 2000 at 03:18:52PM -0800, Fox, Adam wrote: > > > > Yes. pktt will do this. It creates a file in tcpdump format, > > which is convertable into snoop with the right utilities. > > would you folks(NetApp) be willing to share these utilities? As the author of captrans (the utility in question) and the changes to libpcap required to make it read other capture file formats, I don't have any problem making that stuff available. *However*, there's a better program than captrans - editcap. It's part of the Ethereal packet capture/analysis program package: http://ethereal.zing.org/ and uses the same library that Ethereal (and the text-mode - snoop/tcpdump-like - utility Tethereal that also comes with Ethereal) uses to read and write capture files. That library can read more capture file formats than can the patched libpcap I have here, and can also write more formats than can captrans. I don't plan to add any new capture file formats to the patched libpcap, but there are many people who have added new formats to the Wiretap library in Ethereal, and we will probably continue to add new formats as they come up (and as we can figure them out - a lot of the formats were figured out by reverse-engineering, as no documentation was available). Ethereal requires GLib 1.2[.x] and GTK+ 1.2[.x], so you'd have to have them installed on your system in order to build editcap (unless you tweak the Makefile by hand so as to build only the Wiretap library and editcap, in which case you need only GLib 1.2[.x], but once you've installed GLib, you might as well install GTK+ while you're at it), but, once you've done that, you not only have a program to convert capture files, you have a pretty nice GUI packet capture and analysis program, and a pretty nice text-mode packet capture and analysis program as well. (It also runs on Win32 operating systems such as Windows 9x and Windows NT - you have to get versions of GLib, GTK+, and libpcap that have been ported to Win32, but those all exist, and Ethereal can even capture packets on Win32 OSes with that version of libpcap.) There's also, on the "Download" page of the Ethereal Web site, a list of links to binary packages that have been made of Ethereal - or, at least, links to archive sites for binary packages for various OSes - although there's no guarantee that the latest version of Ethereal has been so packaged, in which case the package might not include editcap or Tethereal.

1 0

RE: filer-side packet tracing.
by Haag,Dennis 10 Mar '00

10 Mar '00

I stand corrected, it was introduced in 5.3. I was not aware of it until 5.3.2. -----Original Message----- From: Haag,Dennis [mailto:Dennis.Haag@netapp.com] Sent: Friday, March 10, 2000 6:54 AM To: 'toasters(a)mathworks.com' Subject: RE: filer-side packet tracing. Pktt was introduced in 5.3.2 as an rc_toggle_basic command, it was changed to a regular command in 5.3.4. Although it doesn't show up on the list when you type ? it is there. -----Original Message----- From: Steve Armijo [mailto:armijo@cs.unm.edu] Sent: Friday, March 10, 2000 1:34 AM To: Fox, Adam Cc: 'Ronan Mullally'; toasters(a)mathworks.com Subject: Re: filer-side packet tracing. On Thu, Mar 09, 2000 at 03:18:52PM -0800, Fox, Adam wrote: > > Yes. pktt will do this. It creates a file in tcpdump format, > which is convertable into snoop with the right utilities. would you folks(NetApp) be willing to share these utilities? -s -- Cue the music, fade to black, no such thing as no payback. -PWEI [ armijo(a)cs.unm.edu ]

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters