Dear Michael,
as I could figure out, the problem with UNCONFIRMED is solved. My test
tools is based on lksctp-tools and written for linux testing. Now the
problem here is that there is a inconsistency between linux and
FreeBSD of the return value of spinfo_state. Perhaps these return
values could be standardized in the sctp socket-api. Leaving a note on
the linux dev mailing list on this topic.
The other problem may depend on the fact, that i did the test with
vmware and a remote machine using only one network interface with 2
different Addresses assigned. Furthermore, both addresses had a
netmask of 255.255.0.0 so both addresses were located in the same
subnet. Did the same test with 2 Vmware machines and other addresses
which was successful.
Regards,
Christian
On Jan 17, 2011, at 8:11 AM, Schoch Christian wrote:
I did some test with multihoming and failover. My problem is that
if one transport failes it never comes back to active (no
heartbeats are sent any more).
My setup:
FreeBSD 8.1 Linux 2.6.36
172.16.1.4 --------- 172.16.1.3
172.17.1.4 --------- 172.17.1.3
Packets from 16.1.4 to 17.1.3 and 17.1.4 to 16.1.3 are dropped.
The transfer starts with 172.16.1.4 to 16.1.3 which is working as expected.
Which side is the client, which one is the server? Which side is sending user
data?
If the transfer on this transport failes, it is switching to 17.1.4
& 17.1.3 as expected.
How do you fail the connection? Disconnecting the cable? Configuring
dummynet?
172.16.1.4 gets SCTP_UNCONFIRMED, 172.16.1.3 gets SCTP_INACTIVE
So you mean on the FreeBSD machine you get a SCTP_UNCONFIRMED? For
which address? 172.16.1.3?
Now, if the first connection is available again, the first
transport address of FreeBSD stays at unconfirmed with no HB sent
to 16.1.3
Linux sends HB from 16.1.3 to 16.1.4 with ACK coming back from
17.1.4 to 16.1.3 (which is dropped).
So why are HBs sent from new primary instead of received address ?
As specified in RFC it should sent back from address, it receives
the HB packet.
Correct. Somethings seems strange. Please answer the above and I
will try to reproduce
the problem.
Thanks for the report.
Best regards
Michael
Regards,
Christian
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
