https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13448
--- Comment #29 from Guy Harris <[email protected]> --- (In reply to Stig Bjørlykke from comment #25) > I found this in a mail dated Thu, Jun 23, 2011: > > " > One problem on OSX is the size of the interface address is not equal to the > one on Solaris/Windows, I think this is because an internal struct is used. > This is dissected in dissect_rpcap_ifaddr() in packet-rpcap.c. This only > affects listing the addresses on the remote interfaces, and does not affect > fetching packets. Yes. There are two problems with the "fetch remote interfaces" message: 1) It sends a socket address structure over the wire, but, on systems with a "new BSD"-style socket address structure, the structure begins *not* with a 2-byte address family but with a 1-byte address structure length and a 1-byte address family (that was done when support for the OSI protocols, with variable-length network addresses, was added to BSD). That means that the code that serializes addresses byte-swaps the 1-byte address family field, which turns it into 0, and the code that de-serializes it will not do the right thing if its socket address structures are different from the server's socket address structures. 2) They send the raw address family value over the wire, but different OSes have different values for AF_INET6, so if the server and client have different values for AF_INET6, the IPv6 addresses won't be recognized. I'm working on a change where 1) the server sends a standard structure over the wire, with a layout independent of the OS's socket address structure layouts, including a 2-byte address family field, and always sends the Windows version of AF_INET6; 2) the client checks for a number of address family values, to try to handle servers that have a 2-byte address family field, big-endian servers that have a 1-byte structure length field and a 1-byte address family field, and little-endian servers that have a 1-byte structure length field and a 1-byte address family field, and to handle several different AF_INET6 values. This means that: 1) the fixed client should work with the fixed server *and* with un-fixed servers on most OSes (if I can find out what AF_INET6 is on IRIX and Tru64 UNIX, I could handle them as well - currently, it should handle un-fixed servers on Windows, Linux, *BSD, macOS, AIX, Solaris, and HP-UX); 2) the un-fixed client on Windows should work with the fixed server on all platforms; 3) the un-fixed client on UN*Xes won't work with the fixed server on any platform, but it also wouldn't work with the un-fixed server on Windows or most other UN*Xes, and might not even work with the same UN*X if that UN*X has a 1-byte structure length field and a 1-byte address family field - and the UN*X client, unlike the Windows client, isn't part of a standard *pcap release, so the user should be able to build and use the fixed client. -- You are receiving this mail because: You are watching all bug changes.
___________________________________________________________________________ Sent via: Wireshark-bugs mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs mailto:[email protected]?subject=unsubscribe
