On Tuesday 11 April 2006 00:54, Woodruff, Robert J wrote: > I am not sure this is a openib issue, but perhaps rather a bug in the > utilities that assumed the size of a MAC address is 8 bytes. > > I am not sure if that is the case with this one, but I know it was > the case in some of the user utilities. If this is the case, then > the utility should be fixed.
Here is some new info: on machine X, i got the same failure, on machine Y i got the tcp dump. here are the machines props (same IB driver): on machine X: ------------------- # tcpdump --version tcpdump version 3.8 libpcap version 0.8.3 # tcpdump -i ib1 tcpdump: ioctl: Value too large for defined data type # uname -a Linux X.mtl.com 2.6.9-22.ELsmp #1 SMP Mon Sep 19 18:00:54 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux # cat /etc/redhat-release Red Hat Enterprise Linux AS release 4 (Nahant Update 2) on machine Y: -------------------- # tcpdump --version tcpdump version 3.8 libpcap version 0.8.3 # tcpdump -i ib1 tcpdump: WARNING: arptype 32 not supported by libpcap - falling back to cooked socket tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ib1, link-type LINUX_SLL (Linux cooked), capture size 96 bytes # uname -a Linux Y.mtl.com 2.6.14.3 #1 SMP Mon Jan 9 15:19:18 IST 2006 x86_64 x86_64 x86_64 GNU/Linux # cat /etc/redhat-release Fedora Core release 4 (Stentz) I think that maybe the problem is not in the user level stack or in the utilities , but in the linux kernel (in the module that handles this socket ioctl) Dotan _______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general