Jumbo multicast

Till Straumann strauman at slac.stanford.edu
Thu May 15 19:48:52 UTC 2008


Till Straumann wrote:
> Amedeo Perazzo wrote:
>   
>> Till,
>>
>> These are the problems I see when I try to send jumbo multicast 
>> packets from RTEMS:
>>
>> 1. Packets get fragmented on the 1500 bytes boundary even if I setup 
>> the interface to use jumbo frames.
>>
>> 2. The 2nd fragment of a large packet causes an arp request even if 
>> the original packet is a multicast packet.
>>
>> I suspect that the following points are the causes for the above 
>> behavior.
>>
>> 1. The mtu for the interface is reset to 1500 by ether_ifattach() even 
>> if I set it to 9000 when I initialize the ifnet interface structure. 
>> Note that the RTEMS documentation (at least the version for 4.6.6) 
>> claims that the user should set the mtu variable _before_ calling 
>> ether_ifattach().
>>
>> As a workaround I currently set ifp->mtu _after_ calling 
>> ether_ifattach(). In any case, I claim I should be able to configure 
>> the mtu before calling ether_ifattach().
>>     
> Hmm - not sure about that. Seems that if we require drivers to set 
> if_mtu prior to
> calling ether_ifattach() we possibly break a lot of existing code. IMO 
> setting
> if_mtu after ether_ifattach by drivers which support longer frames should
> be acceptable. Of course, the documentation should be updated...
>   
>> 2. The M_MCAST flag does not get copied by m_copym() for the 2nd 
>> fragment in a packet and, as a consequence, arpresolve() in if_ether.c 
>> does not enter the following condition:
>>
>>         if (m->m_flags & M_MCAST) {    /* multicast */
>>         ETHER_MAP_IP_MULTICAST(&SIN(dst)->sin_addr, desten);
>>         return(1);
>>     }
>>
>> This seems to cause the arp request to be sent when it should not be.
>>
>> What do you think?
>>     
> This one looks more serious. I did only have a quick glance but you may have
> a point there. We should have a look at more recent BSD sources and see
> if and how they fixed this.
>   

This was introduced with netinet/ip_output.c version 1.82
(on 1998/8/23) !! (must have been shortly after the RTEMS port).
Unfortunately, the original BSD CVS IDs are not preserved :-(

--- src/sys/netinet/ip_output.c	1998/08/23 03:07:14	1.81
+++ src/sys/netinet/ip_output.c	1998/09/02 15:11:14	1.82
@@ -31,7 +31,7 @@
  * SUCH DAMAGE.
  *
  *	@(#)ip_output.c	8.3 (Berkeley) 1/21/94
- *	$Id: ip_output.c,v 1.80 1998/08/01 08:44:33 peter Exp $
+ *	$Id: ip_output.c,v 1.81 1998/08/23 03:07:14 wollman Exp $
  */
 
 #define _IP_VHL
@@ -580,6 +580,7 @@ sendit:
 			ipstat.ips_odropped++;
 			goto sendorfree;
 		}
+		m->m_flags |= (m0->m_flags & M_MCAST);
 		m->m_data += max_linkhdr;
 		mhip = mtod(m, struct ip *);
 		*mhip = *ip;


Their CVS log message was:

"Properly fragment multicast packets."

Oouch -- it would be time to update our stack...

T.


> -- T.
>   
>> -- Amedeo
>>     
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>   




More information about the users mailing list