[Sysadmins] SCTP recv problems

[Sysadmins] SCTP recv problems

[Eugene Prokopiev]

Здравствуйте!

Есть некое ПО, использующее SCTP и работающее на одной машине, но не
работающее на другой. И там, и там свежий t7/branch, очевидной разницы
в конфигурации нет. В поисках источника проблемы докатились до того,
что написали маленький SCTP-сервер:

#!/usr/bin/perl

use strict;
use Socket;

my $proto = getprotobyname('sctp');

socket(server, PF_INET, SOCK_RAW, $proto) || die "socket error: $!";
bind(server, sockaddr_in(0, INADDR_ANY)) || die "bind error: $!";

my $buffer;

while (1) {
  print "recv wait ...\n";
  my $paddr = recv(server, $buffer, 65535, 0);
  my ($port, $iaddr) = sockaddr_in($paddr);
  print "recv from [".inet_ntoa($iaddr)."]\n";
}

На одной машине поведение такое:

# ./sctp.pl
recv wait ...
recv from [10.10.10.1]
recv wait ...
recv from [10.10.10.1]

и:

$ tshark -i eth0 -R 'sctp'
Capturing on eth0
  9.304980 10.10.10.1 -> 10.10.10.2 SCTP 86 INIT
  9.305173 10.10.10.2 -> 10.10.10.1 SCTP 50 ABORT
 39.426030 10.10.10.1 -> 10.10.10.2 SCTP 86 INIT
 39.426237 10.10.10.2 -> 10.10.10.1 SCTP 50 ABORT

На другой:

# ./sctp.pl
recv wait ...

и:

$ tshark -i eth0 -R 'sctp'
Capturing on eth1
  5.112609 10.10.10.1 -> 10.10.10.2 SCTP 86 INIT
  6.212575 10.10.10.1 -> 10.10.10.2 SCTP 86 INIT

Куда пропадают INIT-пакеты? Разумеется, iptables на обоих машинах отсутствует.

-- 
WBR,
Eugene Prokopiev

Re: [Sysadmins] SCTP recv problems

[Eugene Prokopiev]

5 февраля 2014 г., 15:03 Eugene Prokopiev написал:

> ... Разумеется, iptables на обоих машинах отсутствует.

Точно также на обоих машинах не загружен модуль sctp, ipv6 выключен,
что еще рассказать? ;)

-- 
WBR,
Eugene Prokopiev

Re: [Sysadmins] SCTP recv problems

[Sergei Epiphanov]

А если сравнить "ip addr" на обеих машинах? Как подозрение, на eth1 адрес не 
10.10.10.2.

-- 
С уважением, Епифанов Сергей

Re: [Sysadmins] SCTP recv problems

[Eugene Prokopiev]

5 февраля 2014 г., 15:27 Sergei Epiphanov написал:

> А если сравнить "ip addr" на обеих машинах? Как подозрение, на eth1 адрес не
> 10.10.10.2.

Идентичная настройка адресов и маршрутов. Собственно, чтоб исключить
подозрение на руки/глаза, обе машины загружались с одной флешки и
далее с той же флешки выполнялся скрипт с rpm -Uvh software.rpm &&
echo ... > /etc/software.conf && ip a add ... && ip r add && service
software start

Ну и там не хаб и не зеркало на свитче, так что пакетов с другим
адресом назначения я просто не увидел бы в tshark.

-- 
WBR,
Eugene Prokopiev

Re: [Sysadmins] SCTP recv problems

[Sergei Epiphanov]

В письме от 5 февраля 2014 15:03:50 пользователь Eugene Prokopiev написал:
> $ tshark -i eth0 -R 'sctp'
> Capturing on eth0
>   9.304980 10.10.10.1 -> 10.10.10.2 SCTP 86 INIT
>   9.305173 10.10.10.2 -> 10.10.10.1 SCTP 50 ABORT
>  39.426030 10.10.10.1 -> 10.10.10.2 SCTP 86 INIT
>  39.426237 10.10.10.2 -> 10.10.10.1 SCTP 50 ABORT

Здесь tshark берет с eth0.

> $ tshark -i eth0 -R 'sctp'
> Capturing on eth1
>   5.112609 10.10.10.1 -> 10.10.10.2 SCTP 86 INIT
>   6.212575 10.10.10.1 -> 10.10.10.2 SCTP 86 INIT

Почему tshark пытается здесь забирать данные с eth1?

-- 
С уважением, Епифанов Сергей

Re: [Sysadmins] SCTP recv problems

[Eugene Prokopiev]

5 февраля 2014 г., 16:47 Sergei Epiphanov написал:

>> $ tshark -i eth0 -R 'sctp'
>> Capturing on eth1
...
> Почему tshark пытается здесь забирать данные с eth1?

Прошу прощения, это опечатка, в обоих случаях следует читать eth0

-- 
WBR,
Eugene Prokopiev

Re: [Sysadmins] SCTP recv problems

[Eugene Prokopiev]

5 февраля 2014 г., 15:03 Eugene Prokopiev написал:

> Есть некое ПО, использующее SCTP и работающее на одной машине, но не
> работающее на другой. И там, и там свежий t7/branch ...

И именно это в сочетании с:

Ethernet controller: Broadcom Corporation NetXtreme BCM5721 Gigabit
Ethernet PCI Express (rev 21)
Subsystem: IBM eServer xSeries server mainboard
...
Kernel driver in use: tg3

является источником проблемы. С любыми другими сетевыми картами (в
т.ч. поддерживаемыми модулем tg3) на t7/branch SCTP-пакеты нормально
извлекаются вызовом recv. Более того, в CentOS 6.5 и Debian 7.4, а
также FreeBSD 8.2 и ALT Linux 4.0 все работает в том числе и на этом
железе.

Сервера эксплуатируются с разными Альтами от 4.0 до t7/branch довольно
давно и особенных проблем с ними до сих пор не наблюдалось. Нынешняя
проблема в некоторых топологиях проявляется иначе - уже на уровне SCTP
не совпадает контрольная сумма, поэтому можно предположить, что в
первом описанном случае контрольная сумма сумма не сходится на уровне
IP и recv ничего не получает.

Пробовал все ядра из t7/branch. Что же не так может быть в наших ядрах
(или где-то еще)?

-- 
WBR,
Eugene Prokopiev