On Sunday 09 June 2002 19:18, Harald Welte wrote: > the results are actually quite interesting - but maybe there's a > particular reason for TCP behaving different than other > protocols...
Broadcast or multicast does not apply to TCP. It does in the other protocols (ICMP / UDP). A broadcast or multicast packet received by TCP is with no doubt a martian as there is no aspect of TCP that can be safely used on other than unicast links. Linux ICMP seems to have some provision to filter out broadcasts when they do not make sense, but it could do better I think.. But I think this aspect of the Linux IP stack can be ignored local traffic. If you receive a broadcast frame addressed to your unicast IP address then the processing should not be much different from receiving a broadcast frame addressed to your broadcast address. The likelyhood that there is TCP/IP implementations sending you broadcast link frames when unicast was intended is very low. But the reverse cannot be assumed. There is special applications of TCP/IP where multicast is used as local transport. This can be seen in some odd active-active load balancing products where all servers must see all packets, so a Linux server/router can be required to receive unicast IP frames from a multicast link source address or to sent unicast IP to a multicast link address.. If this is considered in a bridge environment using the bridge-netfilter integration then obviously no optimization based on unicast/multicast link transport can be done on forwarded packets.. Regards Henrik
