I didnt test udp much, as its not running everywhere here, but now I see you are right.. Seems I should have read HP-UXs docs more closely:

recvfrom() operates in the same manner as recv() except that it is abl
+e to return the address of the socket from which the message was sent
+.  For connected datagram sockets, recvfrom() simply returns the same
+ address as getpeername() (see getpeername(2)).  For stream sockets, 
+recvfrom() retrieves data in the same manner as recv(), but does not 
+return the socket address of the sender.
[download]

So it returns the address for udp, but not for tcp.
You did try it *on* the OSes mentioned, and not *to* them, right? (It should work fine from Linux, at least, it does here.)

Anyfish, I see someone already reported on libnet that the recv line should be changed to check for 'defined', about 8 months ago, and it hasn't been changed yet.. (OTOH the explanation why possibly wasn't very clear) So I'll probably write to him and ask. (Seeing as there was a new libnet recently, just not fixing that bug..)

After looking at various docs I'm now all confused as to whats incorrect. perldoc recv says:

Returns the address of the sender if SOCKET's protocol supports this; 
+returns an empty string otherwise.
[download]

What does it mean with "SOCKET's protocol"? I assumed that meant tcp or udp etc. In which case different behavior on hp and on linux is a bug. If it just means 'supported at all', then it's just a misleading doc.. Further, the recv/recvfrom manpage on Linux says they all return the length of the data received, bah, I'm confused ,)

C.