New fragment overlaps old data retransmission ошибка - Не ошибается лишь тот, кто ничего не делает!

Наиболее частая ошибка, которую видит любой ИТ-специалист, установивший Wireshark и захвативший трафик, это повторная передача TCP пакета (TCP Retransmission). Даже в самой быстрой и правильно настроенной сети происходят потери пакетов и как следствие неполучение подтверждений доставки пакетов от получателя отправителю или обратно.

Это нормально и алгоритмы протокола TCP позволяют отрулить данные ошибки. Поэтому важно понимать, что TCP Retransmission – это симптом, а не причина болезни. Причины могут быть в ошибках на интерфейсах, перегрузке процессоров на сервере или пользовательском ПК, проблемы в пропускной способности каналов связи или фрагментирование пакетов и работа с этим на пути следования пакетов. Внимание надо уделить тому, как много повторных передач и часто они возникают, а не их наличию в принципе.

Анализатор протоколов Wireshark в зависимости от поведения определяет несколько типов повторных передач:

TCP Retransmission – классический тип повторной передачи пакетов. Анализируя трафик Wireshark видит два пакета с одинаковым порядковым номером (sequence number) и данными с разницей по времени. Отправитель пакета, не получив подтверждения получения от адресата по истечении таймера retransmission timer, отправляет пакет повторно автоматически, предполагая, что он потерян по пути следования. Значение таймера подстраивается гибко и зависит от кругового времени передачи по сети для конкретного канал связи. Как он рассчитывается можно узнать в RFC6298 Computing TCP’s Retransmission Timer.
TCP Fast Retransmission – отправитель отправляет повторно данные немедленно после предположения, что отправленные пакеты потеряны, не дожидаясь истечения времени по таймеру (ransmission timer). Обычно триггером для этого является получение нескольких подряд (обычно три) дублированных подтверждений получения с одним и тем же порядковым номером. Например, отправитель передал пакет с порядковым номером 1 и получил подтверждение – порядковый номер плюс 1, т.е. 2. Отправитель понимает, что от него ждут следующий пакет с номером два. Предположим, что следующие два пакета потерялись и получатель получает данные с порядковым номером 4. Получатель повторно отправляет подтверждение с номером 2. Получив пакет с номером 5, отправитель все равно отправляет подтверждение с номером 2. Отправитель видит три дублированных подтверждения, предполагает, что пакеты 2, 3 были потеряны и шлет их заново, не дожидаясь таймера.

TCP Spurious Retransmission – этот тип повторной передачи появился в версии 1.12 сниффера Wireshark и означает, что отправитель повторно отправляет пакеты, на которые получатель уже отправил подтверждение.

Быстрая идентификация повторных передач (TCP Retransmissions) с помощью Wireshark

Первая возможность – это воспользоваться фильтром: tcp.analysis.retransmission:

На экране будут отображены все повторные передачи и указан их тип.

Вторая возможность – это графический анализ повторных передач, когда на графике мы можем выводить несколько графиков и сравнивать их во времени. Также можно сравнить два разных получателя трафика и сделать вывод, в каком сегменте сети происходят больше всего повторных передач вследствие перегрузки сети или оборудования.

Заходим в раздел Statistics – I/O Graph:

На экране откроется окно с графиком, на котором будет отображаться общее количество передач во времени с момента начала захвата трафика. Единица измерения PPS – количество пакетов в секунду.

Далее в окошке под графиком можно добавлять дополнительные графики в зависимости от введенного фильтра и менять стиль вывода информации – график, гисторгамма и т.д. Тут добавлен знакомый нам фильтр: tcp.analysis.retransmission

Далее мы можем провести сравнительный анализ проблем с повторными передачами в сети в целом и между разными пользователями, указав фильтр: ip.src == xxx.xxx.xxx.xxx && tcp.analysis.retransmission

На наш взгляд, анализ повторных передач лучше делать именно в графическом виде, когда мы можем сравнить разные части сети или, например, как здесь можно сделать предположение, что всплески трафика приводят к росту повторных передач, что приводит к возникновению ошибок. Графики интерактивны и кликая на разные участки можно быстро перемещаться во времени, существенно ускоряя поиск.

Напоследок ещё раз напомним – повторные передачи это нормально до тех пор, пока их количество не начинает зашкаливать!

Всегда на связи, Игорь Панов

См. также:

Как включить колонку ACKfor в WireShark?
Перехват паролей с помощью Wireshark
Какие параметры и как измеряются при анализе производительности сервисов и приложений?

Источник

I wrote a proxy server which support http and https connection, When I use with http all work fine, but when I work with https , wireshark report this error
‘Reassembly error, protocol TCP: New fragment overlaps old data (retransmission?)’
Although the browsing work fine but performance is impacted as after this I see TCP RST and because of that SSL negotiation happen again.

Any clue on what could be wrong ?

169.254.119.252 169.254.1.66    TCP 66  54589 > ff-fms [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1
169.254.1.66    169.254.119.252 TCP 60  ff-fms > 54589 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1456
169.254.119.252 169.254.1.66    TCP 54  54589 > ff-fms [ACK] Seq=1 Ack=1 Win=65520 Len=0
169.254.119.252 169.254.1.66    TCP 245 [TCP segment of a reassembled PDU]
169.254.1.66    169.254.119.252 TCP 912 [TCP segment of a reassembled PDU]
169.254.119.252 169.254.1.66    TCP 252 54588 > ff-fms [PSH, ACK] Seq=192 Ack=859 Win=64662 Len=198[Reassembly error, protocol TCP: New fragment overlaps old data (retransmission?)]
169.254.1.66    169.254.119.252 TCP 91  [TCP segment of a reassembled PDU]
169.254.119.252 169.254.1.66    TCP 54  54587 > ff-fms [RST, ACK] Seq=391 Ack=955 Win=0 Len=0

Источник

my app and device use mbedtls

app.txt

Also I saw the Wireshark issue, do you think it could be related to this: https://www.wireshark.org/lists/wireshark-bugs/201508/msg00490.html

It looks like that could be an issue with Wireshark. It looks like if there are Server-Client Certificate frames and Client-Server Certificate frames with the same dtls.handshake.message_seq then that would confuse Wireshark and cause that error message you’re seeing. You can validate this by examining those values.

@hassanctech I upgrade release 1.6.0

use the demo ， but core

cmake .. -DBUILD_STATIC_LIBS=TRUE -DUSE_OPENSSL=OFF -DUSE_MBEDTLS=ON -DBUILD_LIBSRTP_HOST_PLATFORM=x86_64-unknown-linux-gnu -DBUILD_LIBSRTP_DESTINATION_PLATFORM=arm-unknown-linux-uclibcgnueabi

Do you have a stack trace we can look at?

Hmmm. This is not informative. We will need backtrace with thread info to understand what is happening. From this, it is not clear what the source is within the SDK.

the core file only this， cmakelists I have added add_definitions(-g)

Hmm. This does not make a lot of sense. Doesnt look like all thread info is there, unless your application exists as soon as it starts, which does not seem to be the case based on the previous screenshot. Please run your application under GDB and run bt after that. We did have a libwebsocket update from 1.5.0 to 1.6.0, having said that, our travis CI runs clean on ARM platforms. This could also be platform specific. So my next suggestion would be to build libwebsockets on your platform and run a sample application from libwebsocket to see if it runs clean.

Closing due to no response. Feel free to reopen if you have an update.

Источник

У меня возникла следующая проблема. Samba (а может и не самба) начала чудить и периодически внезапно стал пропадать доступ к папкам пользователей и расшареным папкам, а потом опять внезапно появляться. Windows могла не пускать пользователя с первого раза, но пускать через 10 минут или после перезагрузки. При этом, с данной конфигурацией год-два всё работало нормально. Бился я с этой проблемой-бился, не пробился и принял радикальное решение перенести всё на другой сервер, который поднял с нуля (благо давно хотел это сделать). Первую неделю всё работало хорошо, сейчас опять пошли эти симптомы — папки уже то проявляются, то пропадают. При этом порой не пускает по ssh — пишет что-то типа connection refused или coonnection closed by server, так же ошибка мерцающая, в логах следов этого нет. Я не понимаю в чём именно проблема, с самбой, с сетью, с чем-нибудь ещё? Как это проверить? Отдельная беда, что всё это происходит в школе и уже дело доходит до срыва уроков. На сервере стоит только самба и управлялка на Ruby on Rails. Ubuntu 12.04. Даже когда возникают эти ошибки нагрузка на систему небольшая.

В syslog’е из ошибок только регулярная ошибка SASL:

Mar 4 17:49:02 servsmb slapd[1132]: SASL [conn=2934] Failure: no secret in database

В логах самбы по машинам куча мелких ошибок типа таких:

[2014/03/04 14:00:38.670114, 3] smbd/error.c:81(error_packet_set)
error packet at smbd/trans2.c(5238) cmd=50 (SMBtrans2) NT_STATUS_OBJECT_NAME_NOT_FOUND
[2014/03/04 14:00:38.713328, 3] smbd/error.c:81(error_packet_set)
error packet at smbd/nttrans.c(557) cmd=162 (SMBntcreateX) NT_STATUS_OBJECT_PATH_NOT_FOUND
[2014/03/04 14:03:01.969433, 3] smbd/error.c:81(error_packet_set)
error packet at smbd/error.c(161) cmd=162 (SMBntcreateX) NT_STATUS_OBJECT_NAME_NOT_FOUND
[2014/03/04 14:03:01.977544, 3] smbd/error.c:81(error_packet_set)
error packet at smbd/error.c(161) cmd=162 (SMBntcreateX) NT_STATUS_FILE_IS_A_DIRECTORY
[2014/03/04 14:03:01.980004, 3] smbd/error.c:81(error_packet_set)
error packet at smbd/nttrans.c(250) cmd=160 (SMBnttrans) NT_STATUS_BUFFER_TOO_SMALL

smb.conf:

[global]

netbios name = servsmb
workgroup = SCH25-students

server string = %h server
#socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
#hosts allow = 10.0.25.0/255.255.0.0, 127.0.0.1
name resolve order = bcast
wins support = yes
#wins server = 10.0.25.253
dns proxy = no

log file = /var/log/samba/log.%m
log level = 3
max log size = 1000
syslog = 0

panic action = /usr/share/samba/panic-action %d

security = user
encrypt passwords = true

passdb backend = ldapsam:ldap://localhost
idmap backend = ldap:ldap://localhost
#ldaps
obey pam restrictions = no

ldap admin dn = cn=admin,dc=sch25-students,dc=local
ldap suffix = dc=sch25-students,dc=local
ldap group suffix = ou=Groups
ldap user suffix = ou=Users
ldap machine suffix = ou=Computers
ldap idmap suffix = ou=Idmap
ldap ssl = off
; Do ldap passwd sync
ldap passwd sync = Yes
passwd program = /usr/sbin/smbldap-passwd %u
passwd chat = *New*password* %nn *Retype*new*password* %nn *all*authentication*tokens*updated*
add user script = /usr/sbin/smbldap-useradd -m «%u»
ldap delete dn = no
delete user script = /usr/sbin/smbldap-userdel «%u»
add machine script = /usr/sbin/smbldap-useradd -t 0 -w «%u»
add group script = /usr/sbin/smbldap-groupadd -p «%g»
delete group script = /usr/sbin/smbldap-groupdel «%g»
add user to group script = /usr/sbin/smbldap-groupmod -m «%u» «%g»
delete user from group script = /usr/sbin/smbldap-groupmod -x «%u» «%g»
set primary group script = /usr/sbin/smbldap-usermod -g «%g» «%u»

os level = 255
domain logons = yes
domain master = yes
preferred master = yes
local master = yes
time server = yes
admin users = admin

#socket options = SO_KEEPALIVE IPTOS_LOWDELAY TCP_NODELAY SO_RCVBUF=16384 SO_SNDBUF=16384
getwd cache = yes
read raw = yes
write raw = yes
max xmit = 65536
dns proxy = no
name resolve order = wins hosts bcast lmhosts
wide links = yes
unix extensions = no

unix password sync = yes

map untrusted to domain = Yes
# guest account = pcguest
map to guest = nobody
logon drive = P:
#logon path and home doesn’t work for ldap — look pdbedit
logon home = \%N%U
logon path = \%Nprofiles%u

logon script = logon.cmd

usershare allow guests = yes

case sensitive = no
default case = lower
preserve case = yes
short preserve case = yes
dos charset = 866
unix charset = utf-8
display charset = CP1251

[homes]
browseable = no
read only = no
path = /samba/home/%u
comment = %u — Home Directory
create mode = 0775
directory mode = 0775
force create mode = 0775
force directory mode = 0775
invalid users = root join
nt acl support = no
root preexec = /var/www/smbash/clr-recursive-folders %u
hide files = /desktop.ini/$RECYCLE.BIN/
# r
#if [ -h «/samba/home/%u/%u» ]; then rm /samba/home/%u/%u; fi
#/var/www/smbash/clr-recursive-folders %u
#root preexec = /var/www/smbash/set_perm %u
#[incoming]
#comment = Incoming
#browseable = no
#readonly = no
#writeable = yes
#write list = admins
#read list = admins
#path = /var/www
#guest account = pcguest
#guest ok = yes

#invalid users = root, join
#write list = @prog
#force group = prog

[prog]
comment = Prog
browseable = yes
readonly = yes
#writeable = yes
#write list = admins
#read list = admins
create mode = 0664
directory mode = 0775
force create mode = 0664
force directory mode = 0775
#force group = prog
# valid users = @admins
read only = yes
guest account = pcguest
guest ok = yes
write list = @teachers
invalid users = root join

path = /samba/shares/prog

[public]
comment = Public
browseable = yes
readonly = yes
#writeable = yes
#write list = @admins, @teachers
#read list = admins
path = /samba/shares/public
create mode = 0664
directory mode = 0775
force create mode = 0664
force directory mode = 0775
#force group = public
# valid users = @admins
read only = yes
guest account = pcguest
guest ok = yes
write list = @teachers
invalid users = root join

[students]
browseable = yes
comment = Students
path = /samba/home_by/Grades
#force group = teachers
create mask = 0775
force create mode = 0775
#0664
directory mask = 0775
force directory mode = 0775
#force user = teachers
valid users = @teachers
read only = yes
# guest ok = yes
write list = @teachers
#read list = @teachers
invalid users = root join

[netlogon]

comment = Network Logon Service
browseable = no
path = /samba/netlogon/
guest ok = yes
read only = yes

[profiles]
comment = Network Profiles Share
path = /samba/profiles/users
browseable = no
writeable = yes
profile acls = yes
hide files = /desktop.ini/$RECYCLE.BIN/
# r
csc policy = disable
create mode = 0700
directory mode = 0700
force create mode = 0700
force directory mode = 0700
invalid users = root join
nt acl support = no
root preexec = /var/www/smbash/set_perm %u
#root preexec = /usr/local/sbin/smbprofupdate in %u %m %I
#root postexec = /usr/local/sbin/smbprofupdate out %u %m %I
# root preexec = /usr/local/sbin/smbusertraq in %u %m %I
# root postexec = /usr/local/sbin/smbusertraq out %u %m %I
# hosts allow = 10.0.1.0/255.255.255.0, 10.0.10.0/255.255.255.0, 127.0.0.1
# hide files = /desktop.ini
# hide files = /desktop.ini/$RECYCLE.BIN/
# read only = no
# store dos attributes = yes
# create mask = 0600
# directory mask = 0700
# browseable = yes
# guest ok = no
# printable = no
# profile acls = yes
# csc policy = disable
# root preexec = /usr/local/sbin/smbprofupdate in %u %m %I
# root postexec = /usr/local/sbin/smbprofupdate out %u %m %I

# Un-comment the following and create the profiles directory to store
# users profiles (see the «logon path» option above)
# (you need to configure Samba to act as a domain controller too.)
# The path below should be writable by all users so that their
# profile directory may be created the first time they log on
#[profiles]
# comment = Users profiles
# path = /samba/profiles
# guest ok = no
# browseable = no
# create mask = 0600
# directory mask = 0700

[printers]
comment = All Printers
browseable = no
path = /var/spool/samba
printable = yes
guest ok = no
read only = yes
create mask = 0700
[print$]
comment = Printer Drivers
path = /var/lib/samba/printers
browseable = yes
read only = yes
guest ok = no
write list = root, @lpadmin

postexec = /bin/umount /cdrom

Источник

I have an ELK stack locally hosted (v7.0) on a Windows IIS web server and the logs are not making it to the server. Server is running, I can reach the reserved URL and get back the generic json package saying Elasticsearch is running and I can log into Kibana just fine, there’s just no logs to see.

I have a bufferBaseFilename set in the apps that are logging, and when I go to that location the logs are actually there, properly indexed and all. I’m wondering why it never gets synced back to the server? It seems like a connection issue, but all the network stuff checks out. I’m probably missing something simple. Any thoughts? Let me know if you need more information!

asked Jan 16, 2020 at 22:12

A frequent source for this error is a malformed (template) request that does not match your ES version (e.g. contains deprecated fields). You could try to

use a preview version of the nuget package
set DetectElasticsearchVersion to true
set RegisterTemplateFailure to IndexAnyway

You can configure the sink like so:

var loggerConfig = new LoggerConfiguration()
    .WriteTo.Elasticsearch(new ElasticsearchSinkOptions(new Uri(...) ){
        // ...
        DetectElasticsearchVersion = true,
        RegisterTemplateFailure = RegisterTemplateFailure.IndexAnyway
     });

answered Jan 28, 2020 at 15:19

CaringDevCaringDev

8,3811 gold badge24 silver badges43 bronze badges

I had this issue and for me, it was the w3wp.exe process that blocked a couple earlier buffer logs from pushing to elastic search, and everything that came after was also on queue.

I resolved it by killing the process.

answered Sep 4, 2022 at 23:47

Источник