Dear Neil,
Function related to Accept and Bind are listed below.
int SctpAcceptor::accept(
Handle *newHandle,
SctpAssociation *newChannel,
InetAddr *remoteAddrCopy)
{
void *addrPtr = NULL;
SOCKLEN_T peersize = 0;
if (remoteAddrCopy) {
addrPtr = remoteAddrCopy->getAddr();
peersize = remoteAddrCopy->size();
}
SOCKET newSockFd = ::accept((SOCKET)handle.fd, (struct
sockaddr *)addrPtr, &peersize);
if (newSockFd == INVALID_SOCKET) {
int errorCode = errno;
if (errorCode) perror("accept ");
return -1;
} else {
// We should check the validity of the new socket here
//make sure we receive MSG_NOTIFICATION (without this,
we can't read sinfo_ppid correctly)
struct sctp_event_subscribe event;
memset(&event, 0, sizeof(event));
event.sctp_data_io_event = 1;
event.sctp_association_event = 1;
event.sctp_address_event = 1;
event.sctp_send_failure_event = 1;
event.sctp_peer_error_event = 1;
event.sctp_partial_delivery_event = 1;
event.sctp_shutdown_event = 1;
// Must hardcode sizeof(sctp_event_subscribe) to 8;
otherwise will fail
if (::setsockopt(newSockFd, IPPROTO_SCTP, SCTP_EVENTS,
&event, 8) < 0) {
perror("setsockopt(SCTP_EVENTS): ");
// Unable to set socket option
CLOSE_SOCKET(newSockFd);
return -3;
}
Handle h((int *)newSockFd, Handle::SOCKET);
if (newHandle) {
*newHandle = h;
}
if (newChannel) {
newChannel->setHandle(&h); // Once the
handle is set, we can retrieve the local & remote addr
newChannel->setReadStatus(StreamConnection::STATUS_READ_READY);
}
if (!newHandle && !newChannel) {
// Both pointers are null is disallowed.
CLOSE_SOCKET(newSockFd);
return -2;
}
return 0;
}
}
int SctpAcceptor::bind(SOCKET fd, const MultiHomedInetAddr &addr)
{
char ipStr[128];
int rc;
int secondaryAddrCount = addr.getSecondaryAddrCount();
InetAddr primaryAddr = addr; // Get the
primary address first
if (secondaryAddrCount == 0 && primaryAddr.getPort() == 0) {
return -1; // Acceptor must have a port to bind
}
primaryAddr.getIp(ipStr);
printf("fd=%d. Binding to primary addr %s:%d...\n", (int)fd,
ipStr, primaryAddr.getPort());
// We must call bind() first before calling bindx()
if ((rc = ::bind(fd, (struct sockaddr *)primaryAddr.getAddr(),
primaryAddr.size())) < 0) {
int errorCode = errno;
if (errorCode) perror("bind ");
}
if (!rc && secondaryAddrCount > 0) {
SOCKADDR_IN *addrList = new SOCKADDR_IN[secondaryAddrCount];
addr.getSecondaryAddr(addrList, secondaryAddrCount);
for(int i=0; i<secondaryAddrCount;i++) {
char ip[32];
inet_ntop(addrList[i].sin_family, &addrList[i].sin_addr, ip,
(addrList[i].sin_family == AF_INET) ?
INET_ADDRSTRLEN : INET6_ADDRSTRLEN);
unsigned port = ntohs(addrList[i].sin_port);
printf("Bind to secondary (%s : %d)\n", ip, port);
}
rc = sctp_bindx(fd, (struct sockaddr *)addrList,
secondaryAddrCount, SCTP_BINDX_ADD_ADDR);
delete [] addrList;
if (rc < 0) {
int errorCode = errno;
if (errorCode) perror("bindx ");
}
}
// No need to close the socket if rc < 0, because outer
function will close it for us
return rc;
}
Regards,
Andrew
On Fri, Nov 8, 2013 at 12:18 PM, tsoi andrew <tsoiandrew@xxxxxxxxx> wrote:
> Dear Neil,
>
> For more information, our application make use of
> lksctp-tools-1.0.9-1.src in redhat Linux 6 64 bit environment
>
> Regards,
> Andrew
>
> On Fri, Nov 8, 2013 at 11:35 AM, tsoi andrew <tsoiandrew@xxxxxxxxx> wrote:
>> Dear Neil,
>>
>> The 176 routing is ok because when I shift 172.28.129.176 to primary address.
>> The 176 can be establish but 48 failed.
>> I guess it is related to primary and secondary setting. Can secondary
>> IP be established also?
>>
>> sctp 172.28.129.176:9082
>> LISTEN
>> 172.28.129.48:9082
>>
>> sctp 0 0 172.28.129.176:9082 10.82.29.240:9082
>> ESTABLISHED
>> Regards,
>> Andrew
>>
>> On Thu, Nov 7, 2013 at 10:16 PM, Neil Horman <nhorman@xxxxxxxxxxxxx> wrote:
>>> On Thu, Nov 07, 2013 at 11:45:25AM +0800, tsoi andrew wrote:
>>>> Dear Neil,
>>>>
>>>> Attached file is our tcpdump.
>>>> Now our secondary IP doesn't work.
>>>> Please advise. Thanks.
>>>>
>>>> IP info:
>>>> lksctp primary IP is 172.28.129.49
>>>> lksctp secondary IP is 172.28.129.176
>>>>
>>>> Client IP is 10.82.29.240/10.82.29.241
>>>>
>>>>
>>> I think you mean the lksctp primary is 172.28.129.48, not 49, but no matter.
>>>
>>> Looking at this, its not just heartbeats that arent getting answered, nothing is
>>> getting responded to via the 176 address. The only data that I see come out of
>>> that address are two abort frames (not sure what the cause is there yet).
>>>
>>> I would start by verifying basic connectivity via that address. I'd try
>>> something like:
>>> ping -I 172.28.129.176 10.82.29.240
>>> and
>>> ping -I 172.28.129.176 10.82.29.241
>>>
>>> while running a tcpdump on the interface that holds the 176 address specifically
>>> to make sure that you're routing tables locally and network in generally can
>>> pass traffic over that address
>>>
>>> Neil
>>>
>>>>
>>>>
>>>>
>>>> Regards,
>>>> Andrew
>>>>
>>>> On Thu, Nov 7, 2013 at 10:43 AM, tsoi andrew <tsoiandrew@xxxxxxxxx> wrote:
>>>> > Dear Neil,
>>>> >
>>>> > For more information, our secondary IP doesn't response COOKIE_ECHO
>>>> > also. Only our primary IP can response COOKIE_ECHO with COOKIE_ACK.
>>>> >
>>>> > Regards,
>>>> > Andrew
>>>> >
>>>> > On Thu, Nov 7, 2013 at 10:36 AM, tsoi andrew <tsoiandrew@xxxxxxxxx> wrote:
>>>> >> Dear Neil,
>>>> >>
>>>> >> Please find my network diagram first.
>>>> >> Now at server side, can't see our lksctp client 4 connection but only
>>>> >> 2 2 connection. The reason is that heartbeat ACK not found.
>>>> >>
>>>> >> Regards,
>>>> >> Andrew
>>>> >>
>>>> >> On Mon, Nov 4, 2013 at 8:09 PM, Neil Horman <nhorman@xxxxxxxxxxxxx> wrote:
>>>> >>> On Mon, Nov 04, 2013 at 09:59:44AM +0800, tsoi andrew wrote:
>>>> >>>> Dear Sir,
>>>> >>>>
>>>> >>>> I got a problem when set multi-homing to active/active.
>>>> >>>> That mean, It is expected that our lksctp server have 2 IP to connect
>>>> >>>> 2 IP of destination client with total 4 connections.
>>>> >>>> The flow is that client send "INIT" message with 2 (primary and
>>>> >>>> secondary) IP to our server and lksctp server return INIT_ACK. But
>>>> >>>> when second client send 'heartbeat' to us, lksctp server cannot return
>>>> >>>> ACK.
>>>> >>>> Moreover, we already proved our connectivity correct because when our
>>>> >>>> lksctp server send heartbeat to both destination client and they can
>>>> >>>> return ACK.
>>>> >>>> Would you mind sharing if lksctp lib already configure those
>>>> >>>> multi-homing purpose.
>>>> >>>>
>>>> >>> Can you provide a network diagram and a tcpdump of your connection?
>>>> >>> Neil
>>>> >>>
>>>> >>>>
>>>> >>>>
>>>> >>>> Best Regards,
>>>> >>>> Andrew Tsoi
>>>> >>>> --
>>>> >>>> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
>>>> >>>> the body of a message to majordomo@xxxxxxxxxxxxxxx
>>>> >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>> >>>>
>>>
>>>
--
To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
