Menu
▾
▴
#3 TRDPSTATS: Incorrect counter for received packets on dual interface (XLS #131)
In the case that an End Device receives MD packet in multicast with dual interfaces for two Ethernet sub-networks but one of the cables (for sub-network #2) is removed, the statistics data gotten from the sub-network #2 by the appHandle in tlc_getStatistics() shows the same value as that from the sub-network #1.
In this case, since no packet is received at the sub-network #2, the statistics data shall not be counted up.
As the socket for multicast receiving is created with IP address "0", when the sub-network #2 is not in operation, the socket for sub-network #2 receives the packets with the sub-network #1.
The statistics data shows the value of the appHanlde which the receiving socket belongs to, not by the sub-network received.
The statistics data shall be individual for each sub-netowok interface.
The socket shall recognize the sub-network in which the packet is received.
If the sub-network received is identified as the sub-network which the receiving socket belongs to, then the statistics data shall be counted up.
BL 2013-07-21: Receiving Multicasts cannot be chained to an interface (on Linux). A socket receiving multicasts must be bound either to 0 (INADDR_ANY) or to the multicast address (see issue #14). In any case, every socket will receive (and process) incoming MC packets. If we'd change this (binding to MC address), the whole socket handling has to be changed (i.e. each MC join needs its own socket). Even then we cannot easily decide where a packet came in, if we listen for the same MC on both interfaces. Currently, I have no ideal solution...
AHW 2013-07-23: vos_getInterfaces() shall in VOS_IF_REC_T additionally provide the information for link up/down. Statistics data itself shall be untuched.
Last edit: Armin-Hagen Weiss 2013-11-11
fixed for win32 and posix, fix for vxworks will follow
Postponed for next major release.
For the moment there is no solution to handle this.