From: Neil H. <nh...@tu...> - 2008-05-27 00:56:07
|
On Mon, May 26, 2008 at 05:31:19PM +0200, Ivan Skytte Jørgensen wrote: > On Saturday 24 May 2008 21:20:39 Ivan Skytte Jørgensen wrote: > > On Saturday 24 May 2008 20:31:40 Neil Horman wrote: > > > On Sat, May 24, 2008 at 10:46:13AM +0200, Ivan Skytte Jørgensen wrote: > > > > One of my users of the JavaSCTP library reports that linux cannot > > > > connect to Solaris 10 update 3. > > > > > > > > His hypothesis so far is that the INIT chunk sent by linux contains > > > > parameter types with the 2 MSB bit set (11 = "skip this parameter and > > > > continue processing, but report error") including ECN, forward TSN and > > > > a adaptation layer indication. and Solaris chokes on it. > > > > > > > > One interesting bit is that neither my library nor the application > > > > specifies adaptation layer indication yet linux seems to send it > > > > anyway. > > > > > > I'll look into why this might be happening. Do you have a tcpdump of > > > the association in question? > > > > Not from my user (yet). > > I have one now at http://i1.dk/g/capture1.pcap > > It looks very weird. The linux client sends two INIT (I don't know why - it is > not supposed to do that) and then the solaris server responds with one ABORT > which nothing interesting in it. I have no clue what is going on. > > Regards, > Ivan It does look rather wierd. More than that, it looks wrong, from the IP layer down. I know it doesn't need to, but even the ip identification field isn't updating between pairs of INIT chunks. Its almost as if something is duplicating packets. I notice that you're running your client on a vmware guest, which IIRC is tied to the bare metal networking via a software bridge interface. I wonder if something odd about the configuration is causing duplicate packages to be received by the solaris host. Does this same behavior happen if you run the linux client on bare metal? Neil |