Если вы создадите общий ресурс smb/cifs на своем ноутбуке с Linux, вы сможете подключить его на обоих других устройствах. На Android приложения файлового менеджера, такие как «fileManager HD» или «ES FileManager», смогут открывать сетевые папки SMB.
для этого есть инструмент "часы" или вы можете while true; do sleep 2; clear; ss -tulnp | grep 1234 ; done
вы можете добавить код в файл и отслеживать его. который, вероятно, будет генерировать загрузку процессора, но может помочь вам с тем, что вы ищете.
Команда наблюдения Linux
Есть два инструмента, которые можно использовать для мониторинга событий TCP connect
в Linux:
Разница между ними заключается в том, что первый предоставляет параметры для настройки вывода (, например фильтрацию по PID или номеру порта ), а второй представляет собой более упрощенный инструмент и не предоставляет замысловатых опций.
В вашем случае самым простым вариантом будет установка bcc и запуск:
tcpconnect.py -P 1234
Если вы устанавливаете эти инструменты с помощью диспетчера пакетов вашего дистрибутива, имейте в виду, что некоторые дистрибутивы не помещают tcpconnect
в /usr/bin
, а вместо этого помещают их куда-нибудь еще, например, в /usr/share
. Поэтому обязательно проверьте, где ваш дистрибутив помещает эти файлы, если вы не можете их найти.
Программа ss
использует сокет netlink sock_diag(7)
для получения информации о сокетах. Но интерфейс sock_diag
не поддерживает режим «мониторинга»/просмотра/прослушивания, как это делает rtnetlink(7)
. Вы можете выполнять только запросы через сокет sock_diag
.
Однако вы можете перехватывать пакеты tcp syn (=connect )через pcap/tcpdump и использовать интерфейс sock_diag
для поиска информации о них.
Но с этим есть как минимум три серьезные проблемы:
все утилиты командной строки, способные запрашивать и отображать эту информацию (ss
,lsof
)очень жесткие, и практически невозможно настроить формат их вывода или позволить им действовать как фильтр.Все, что вы можете сделать из командной строки, это запустить отдельный экземпляр ss
для каждого пакета.
это пикантно; процесс может быть уже завершен за время между захватом пакета и запросом информации о процессе.
tcpdump
так же легко использовать из скрипта, как ss
или lsof
.
Имея все это в виду, что-то вроде этого может помочь или, по крайней мере, может быть началом:
socmon(){
script /dev/null -qc "tcpdump -qn -iany '
((tcp[tcpflags] & tcp-syn) != 0 or (ip6 and (ip6[13 + 40] & 2) == 2)) and ($*)
' 2>/dev/null" </dev/null |
perl -ne 'print; next unless /(\S+)\.(\d+) >/; print qx(ss -Hp src "[$1]:$2") =~ s/.*users:/\t/r'
}
Использование:
>>> socmon dst port 9999
07:14:59.700995 IP6 fe80::89c8:7f7c:29f5:78df.50720 > fe80::89c8:7f7c:29f5:78df.9999: tcp 0
(("xxx",pid=15805,fd=1),("xxx",pid=15804,fd=0))
07:15:08.868555 IP 127.0.0.1.42784 > 127.0.0.1.9999: tcp 0
(("xxx",pid=15851,fd=1),("xxx",pid=15850,fd=0))
07:15:17.055518 IP 172.31.255.1.39700 > 172.31.255.1.9999: tcp 0
(("xxx",pid=15856,fd=1),("xxx",pid=15855,fd=0))
script /dev/null... </dev/null
заставляет tcpdump
использовать буферизацию строк; tcpdump -l
НЕ будет обходиться без искусственной задержки между захватом пакета и его печатью.
(ip6 and (ip6[13 + 40] & 2) == 2)
проверяет, является ли это пакетом SYN ВРУЧНУЮ, потому что tcp[tcpflags] & tcp-syn
не работает с IPv6.
Perl извлекает исходный адрес и порт из вывода tcpdump, вызывает ss
с ними в качестве аргумента фильтра и обрезает вывод ss
, чтобы показать только информацию о процессе.
Вы можете перенаправить порты с iptables или nftables на другой порт, где прослушивающая программа сможет получить информацию о своем партнере до того, как примет соединение, а затем перенаправит соединение к месту назначения. Это устранит как гонку, так и не будет сбит с толку процессами, которые куда-то подключаются, а затем либо передают, либо пропускают дескриптор файла сокета другим процессам.
watch -n 1 -d 'lsof -n -itcp:1234'
не логирование, а мощный мониторинг в реальном -времени с подсветкой...
$ man watch
$ man lsof