Date: Sat, 3 Jan 2009 00:20:14 +0100 From: =?ISO-8859-1?Q?Michael_T=FCxen?= <Michael.Tuexen@lurchi.franken.de> To: "Li, Qing" <qing.li@bluecoat.com> Cc: qingli@freebsd.org, Randall Stewart <rrs@lakerest.net>, current@freebsd.org, FreeBSD Net <freebsd-net@freebsd.org> Subject: Re: SCTP related issue with recent ARP changes? Message-ID: <FF7A129F-38C4-4C16-89E9-67678882C5E9@lurchi.franken.de> In-Reply-To: <B583FBF374231F4A89607B4D08578A4302B92332@bcs-mail03.internal.cacheflow.com> References: <A3B60541-1902-421D-A57B-C554B93AF912@lurchi.franken.de> <B583FBF374231F4A89607B4D08578A431442FE@bcs-mail03.internal.cacheflow.com> <B583FBF374231F4A89607B4D08578A4302B92332@bcs-mail03.internal.cacheflow.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Qing, I have tested your patch and it works! Thanks you very much for your help. Best regards Michael On Jan 2, 2009, at 11:15 PM, Li, Qing wrote: > Hi Michael, > > The SCTP problem you were having was attributed to the arp-v2 changes. > The reason TCP and UDP works well is because the TCP and UDP > modules does not supply a route entry when calling ip_output(). > Consequently in ip_output() the destination (sockaddr) was =20 > reinitialized > and the sin_port field is 0. > > The destination sockaddr supplied in the route entry from the SCTP > module has the actual port value in it. > > The new L2 search was (initially) written as a generic function. > So the L3 address comparison was performed using bcmp() of =20 > sockaddr_len > bytes. The L2 entry was created with a sockaddr object that includes > the port value, however, on ARP input the port value does not > apply. The mismatch in port value causes the ARP lookup to fail > and the SCTP connection never complete its negotiation. > > Please apply the patch for IPv4 in my home directory at > http://people.freebsd.org/~qingli/in.c.diff > > I did the basic testing using the programs you gave me and now > the client connects successful and completes the transfer. I also > verified the packets in wireshark trace. > > Please let me know if this patch fixes your SCTP problems. > > Thank you for your help. > > -- Qing > > >> -----Original Message----- >> From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd- >> current@freebsd.org] On Behalf Of Li, Qing >> Sent: Thursday, January 01, 2009 12:17 PM >> To: Michael T=FCxen; FreeBSD Net >> Cc: qingli@freebsd.org; current@freebsd.org >> Subject: RE: SCTP related issue with recent ARP changes? >> >> >> Hi Michael, >> >> Your problem could be related to the recent ARP changes. >> I will investigate further to confirm. >> >> Thanks, >> >> -- Qing >> >> >> -----Original Message----- >> From: owner-freebsd-net@freebsd.org on behalf of Michael T=FCxen >> Sent: Thu 1/1/2009 8:59 AM >> To: FreeBSD Net >> Subject: SCTP related issue with recent ARP changes? >> >> Dear all, >> >> I'm running the current CVS version of FreeBSD 8 in a virtual >> machine using VMWare 2.0.1 on a Mac (not sure if this is relevant) >> and bridged networking having an em interface on the virtual machine. >> I'm using a similar setup with older FreeBSD machines and they are >> running fine. >> >> Loopback communication based on UDP, TCP, SCTP or ICMP works fine. >> >> Communicating with other hosts using UDP, TCP or ICMP works fine. >> >> Communicating with other hosts using SCTP does not work. >> The SCTP stack calls ip_output() and an ARP request for the >> correct destination IP address is send out. A corresponding >> ARP reply is visible in Wireshark (running on the FreeBSD 8 box) >> and looks good. However, the corresponding SCTP packet it never >> sent out. I'm not sure, but this might be related to the >> recent ARP changes. Is there anything required from the >> transport layer to be done when calling ip_output() that >> was not required before? >> >> Best regards >> Michael >> > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FF7A129F-38C4-4C16-89E9-67678882C5E9>