4020 multicast Discussion

Dizzy, the article just sent is gone, and csdn is too frustrating. It's hard to write an article and submit it without responding.

Recently, I was testing the sep4020 network. Because many Nic drivers that have been porting 4020 are not very familiar with the multicast part, but it was also directly transplanted like someone else's driver. Recently I wanted to test whether 4020 of multicast is supported. So I went online and looked for several articles, and then started setting. (1) First of all, let the Linux Kernel support the multicast protocol. In the network protocol stack section of menuconfig, select the corresponding option Multicast: [*] IP: multicasting │ [*] IP: Advanced router │ choose IP: fib lookup algorithm (choose fab_hash if unsure) (fiber hash) ---> │ [*] IP: multicast Routing │ [*] IP: PIM-SM version 1 Support │ [*] IP: PIM-SM version 2 support hook the corresponding options, re-compile the kernel, restart the board, check whether the subboard supports multicast ifconfig eth0 to display up broadcast running Multicast. multicast is supported. (2) Now that the kernel supports it, you can configure the multicast IP address of the NIC. In this step, I searched the internet for a configuration and test the multicast program, after downloading the program, there is no problem in cross-Compiling. It is not reflected and the program is suspected. Therefore, the program is compiled and run under ora on the computer, which is normal, it seems that the NIC Driver still has a problem. Print the information in the sepether_sethashtable () function of the NIC Driver. Normally, it seems that the multicast configuration of 4020 has encountered a problem, I don't know how to use the two registers, Mac hash0 and Mac hash1 of 4020. They just do what they look like. It seems that there may be problems here. Paste the following code: static int hash_get_index (_ u8 * ADDR) {int I, j, bitval; int hash_index = 0; For (j = 0; j <6; j ++) {for (I = 0, bitval = 0; I <8; I ++) bitval ^ = hash_bit_value (I * 6 + J, ADDR ); hash_index | = (bitval <j);} return hash_index;}/** add multicast addresses to the internal multicast-hash table. */static void sepether_sethashtable (struct net_device * Dev) {struct dev_mc_list * curr; unsigned long mc_fi LTER [2]; unsigned int I, bitnr; mc_filter [0] = mc_filter [1] = 0; curr = Dev-> mc_list; for (I = 0; I <Dev-> mc_count; I ++, curr = curr-> next) {If (! Curr) break;/* unexpected end of list */bitnr = hash_get_index (curr-> dmi_addr ); mc_filter [bitnr> 5] | = 1 <(bitnr & 31);} sep_emac_write (mac_hash1_v, mc_filter [1]); sep_emac_write (mac_hash0_v, mc_filter [0]);} /** enable/disable promiscuous and multicast modes. */static void sepether_set_rx_mode (struct net_device * Dev) {unsigned long CFG; CFG = sep_emac_read (mac_ctrl_v); If (Dev-> flags & iff_promis C)/* enable promiscuous mode */CFG | = 0x20; else if (Dev-> flags &(~ Iff_promisc)/* disable promiscuous mode */CFG & = ~ 0x20; If (Dev-> flags & iff_allmulti) {/* enable all multicast mode */sep_emac_write (mac_hash1_v, 0 xffffffff); sep_emac_write (signature, 0 xffffffff ); CFG | = 0x10;} else if (Dev-> mc_count> 0) {/* enable specific multicasts */sepether_sethashtable (Dev); CFG | = 0x10 ;} else if (Dev-> flags &(~ Iff_allmulti) {/* disable all multicast mode */sep_emac_write (mac_hash1_v, 0); sep_emac_write (mac_hash0_v, 0); CFG & = ~ 0x10;} sep_emac_write (mac_ctrl_v, CFG);} the code is annoying because it has some hash table operations in the middle, so it cannot be viewed, I can understand it. When we configure a multicast IP address, the underlying layer will convert it into a multicast MAC address. Then, this program will divide the multicast MAC address into 64 parts, if the MAC address you configured is the address range, it will set the corresponding location of the two registers in the middle of a total of 64 bits, this allows the NIC to filter out the corresponding multicast packets when sending and receiving packets at the underlying layer. The principle is that, but why do we still not work for 4020? Dizzy, it seems that we have to see it wrong. Why ??? (3) process for the network adapter to receive multicast packets: after joining the multicast group operation, the network device interface knows that it wants to receive the datagram of the group, therefore, the multicast data is received from the network card and reaches the myip_rcv function. We start from the myip_rcv function and track the process of receiving multicast data packets.
Similarly, myip_rcv should first check the datagram type (whether it is the packet to be received by the local machine), check whether the IP header is correct, and then call myip_rcv_finish. Myip_rcv_finish first searches for the input route for any datagram. The input route lookup function is myip_route_input. When the function cannot find the corresponding route entry in myrt_hash_table, it judges the input address of the datagram, if the IP address is a multicast address, you cannot simply search for fib. Instead, you must perform special operations.
First, call myip_check_mc to check the multicast datagram and match the multicast address from the struct in_device of the network device interface. If the multicast address does not match, this is not the multicast packet we want to receive, discard. If an IGMP Packet exists, the next check is performed. If this packet is an IGMP packet, it is received. Otherwise, check the filtering mechanism set by this multicast group in our struct in_device, if the source address of the datagram is in our Filter list, it is discarded; otherwise, it is received.
If the packet is received, call myip_route_input_mc to find the multicast input route. This is a function specially set for multicast. The first step is to check the validity of the datagram source address, that is, the source address cannot be a multicast address, a broadcast address, or a loop address. At the same time, the datagram must be an Internet Protocol package (eth_p_ip ). If the source address is 0, only the value between 224.0.0.0-224.0.0.255 and 224.0.0.255 can be transmitted only in the subnetwork of the sending host, but not through the router .) The system can select a source address with the scope rt_scope_link. Otherwise, an error occurs.
After verifying the validity of the source address, we create a route entry, that is, the struct rtable. The rt_type value of this route entry is rtn_multicast, indicating this multicast route. For multicast packets received locally, we set the receiving function to myip_local_deliver.
With this route entry, we can call myip_local_deliver to continue to receive the process. This part of the process has been described many times before, so it is a little simpler, just pay attention to the unique multicast. Similarly, after myip_local_deliver_finish, first check whether there is a raw socket to receive this multicast package. Then, according to the protocol field in the IP header, call the receiving function of the corresponding protocol. We are using a UDP multicast packet, so we call myudp_rcv.
Myudp_rcv first checks the route entry member rt_flags. if it finds that it has rtcf_broadcast or rtcf_multicast, it will not go through the regular match from myudp_hash to find the socket, put the datagram into the receiving queue. Instead, call the myudp_v4_mcast_deliver function, which is used to receive UDP multicast data packets. It first determines the location in the mydup_hash hash table based on the destination port and then traverses the linked list. Compared with normal UDP datagram reception, it has an additional filtering check, that is, find the ip_mc_socklist item corresponding to the group to which the datagram belongs in the mc_list Member of the socket struct, and view its filtering configuration, check whether the source address of the datagram is in the filter list. If not, the data is placed in the receiving queue of the socket to receive multicast data packets. It seems that you have to work hard !!