Messages in this thread | | | Date | Fri, 9 Apr 1999 09:22:14 +0500 (GMT) | From | CyberPsychotic <> | Subject | linux recvfrom differencies |
| |
There was a sort of discussion raised at euro-coders mailing list recently which related to the differencies in implementation of recvfrom() call in linux socket API and the rest of Unixes (Solaris and two BSD clones (BSDi and FreeBSD were tested).
We played with a sort of self-made udp echo daemon, which basically was listening to the udp packets on certain port and was sending them back to the same IP:port-no. The curious thing is that if the packet is spoofed, and no port is being listened on remote machine (and icmp port unreachable goes back) linux returns -1 for next recvfrom with herrno(?) set to REFUSED, while BSD/Solaris just ignore this.
The question is: is there any paper/RFC/FYI which puts a standard on such things, or this is basically `the matter of taste' of OS developers, and thus just should being watched carefully, while developing multi-platform applications?
thanks ahead
regards Fyodor
---------- Forwarded message ---------- Date: Thu, 8 Apr 1999 18:05:13 +0500 From: stealth@dione.ids.pl Reply-To: euro-coders@gizmo.kyrnet.kg Subject:Re: TCP/IP-stack obscurities #2
>yeah.. I also tested the same thing on Solaris and got the similar >behaviour. Seems that Linux is again the only `spoiled kid'. The thing >appears in recvfrom call, and whenever kernel receives ICMP port unreach. >packet it probably returns this call with `connection refused' errie. >Whether this is correct or not, I have no clue, but it would be worth to >check out POSIX(?) notation. POSIX.1 doesn't spec NET-stuff :-( socket_call() which leads to recvfrom() is linux-specific in this way. Maybe RFC 793 (tcp?) says more...
: ---- main(){fork();main();} ---- : Stealth - atexit(main) to call me again. : stealth@gizmo.kyrnet.kg <-> http://www.kalug.lug.net/stealth
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |