[one_eight_seven 7]

Даже недорогие свитчи предлагают port mirroring.

[HardEgor 140]

12 часов назад, addi II сказал:

net_connnew это же дефайн в апи.h

Я этот заголовочник влключаю, поидее вопросов таких не должно быть

Я так и не уловил, вам надо Raw API(event-driven, без ОС, все функции начинаются с tcp_) или Netconn API(для использования в ОС, все функции начинаются с netconn_)?

[addi II 1]

22 hours ago, HardWareMan said:

Если посылаете с 192.168.0.40 на 192.168.0.2 а подслушиваете обмен на 192.168.0.1, то следует вместо свича (switch) использовать концентратор (hub).

Почему?, сетка же вроде одна и та же?

 

6 hours ago, HardEgor said:

Я так и не уловил, вам надо Raw API(event-driven, без ОС, все функции начинаются с tcp_) или Netconn API(для использования в ОС, все функции начинаются с netconn_)?

да, в вшеприведенном коде я уже перешел на tcp после безуспешных попытках завести netconn без ОС. 

[HardEgor 140]

18 минут назад, addi II сказал:

Почему?, сетка же вроде одна и та же?

Чтобы проверить в винде, в командной строке наберите "arp -a", компьютер выдаст список ip-адресов, которые знает(с которыми он коннектился)

[HardWareMan 15]

27 minutes ago, addi II said:

Почему?, сетка же вроде одна и та же?

Свитч оперирует не сетью а МАСами (управляемый ещё и IP). Когда свитч получает пакет, МАС назначения которого он не имеет в своей памяти он его действительно отсылает на все порты (кроме, очевидно, того, откуда пакет пришёл). Если свитч принял ответ с этим МАСом с конкретного порта, то он записывает этот МАС+ПОРТ в свою память и следующие все пакеты на этот МАС полетят в конкретный порт, пока не произойдёт таймаут или запись этого МАСа не вытеснится из буфера другими МАСами (тут у производительных свичей больше буфер, чем у дешёвых). Этим и отличается свитч от концентратора, который всегда все пакеты отсылает на все свои порты. Это уменьшает число коллизий при нагрузке в сети, т.к. устойчивые передачи между парами МАС могут не пересекаться на портах, только внутри кросс-шины самого свича, а она сильно быстрее скорости гнёзд, особенно для свичей FE и ниже. Эта модель поведения и является причиной названия этого типа оборудования: он логически переключает порты между собой.

[dimka76 84]

On 9/16/2025 at 11:03 AM, HardWareMan said:

Если посылаете с 192.168.0.40 на 192.168.0.2 а подслушиваете обмен на 192.168.0.1, то следует вместо свича (switch) использовать концентратор (hub).

Или компьютер с двумя сетевыми картами.
И снифери сколько хочешь и чего хочешь.

[HardWareMan 15]

3 minutes ago, dimka76 said:

Или компьютер с двумя сетевыми картами.
И снифери сколько хочешь и чего хочешь.

Насколько я понял, у чеовека связь между двумя сторонними устройствами, которые используют среду ethernet. И одно явно не поддерживает акулу (это устройство для которого пишется софт) а про второе мы не знаем, кроме IP. А слушать обмен предполагалось третим устройством с другим IP.

[arhiv6 25]

В 16.09.2025 в 23:39, one_eight_seven сказал:

Даже недорогие свитчи предлагают port mirroring.

Да, вы правы. Я ранее ни разу с такими не работал - или роутеры использовал, или простые неуправляемые коммутаторы. Про управляемые как-то не подумал. Как пример из первых попавшихся: D-Link DGS-1100-05V2 имеет port mirroring в режимах One-to-One и Many-to-One. Как раз второй вариант для захвата трафика между устройствами подойдёт.

[addi II 1]

22 hours ago, arhiv6 said:

Да, вы правы. Я ранее ни разу с такими не работал - или роутеры использовал, или простые неуправляемые коммутаторы. Про управляемые как-то не подумал. Как пример из первых попавшихся: D-Link DGS-1100-05V2 имеет port mirroring в режимах One-to-One и Many-to-One. Как раз второй вариант для захвата трафика между устройствами подойдёт.

Спасибо, но я не совсем понял.

У меня действительно два сторонних устройства, - 1 ) Установка с адресом 192.168.0.40; 2) Nucleo429ZI с адресом 192.169.0.2; 3) Ноут

Я ноуту поменял IP на 192.168.0.1, на нем стоит акула

Cоединил все через switch, коннект Nucleo с устоновкой вроде как произсодит в этой сети, в акуле вижу arp устаовки к NUCLEO и все, передачи строки не вижу, которая в коде, приведенным выше

По поводу маршрутизатора, я думал что это более сложный вариант, ведь его надо настраивать, как минимум менять его IP

Сейчас я правда еще более упростил отладку, подскоединил NUCLEO к ПК и на ПК поменял адрес на адрес установки. Поидее акула на том же ПК сможет промониторить эту сеть без свича и установки

 

Edited September 18 by addi II

[addi II 1]

Попробовал с этой конфигурации, и все также нет посылки, акула показывает что STM делает широковещательный ARP Announcment и далее Who has 192.168.0.40?

И далее никаких соощений

Отладка показывает по коду что соединение было

Ничего не понимаю....

[HardEgor 140]

28 минут назад, addi II сказал:

И далее никаких соощений

Да уж, замечательная у вас диагностика) Даже подсказывать нечего)

Первый вариант - потрассировать в отладчике.

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

Третье, насколько помню, в самом lwip есть режим DEBUG

[addi II 1]

21 hours ago, HardEgor said:

Да уж, замечательная у вас диагностика) Даже подсказывать нечего)

Первый вариант - потрассировать в отладчике.

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

Третье, насколько помню, в самом lwip есть режим DEBUG

посмотрел еще раз в дебаге, и два момента не понятны

1) функция tcp_connect проходит успешно но при этом я в отладке не вхожу в функцию tcp_echoclient_connected

void tcp_echoclient_connect(void)
{
  ip_addr_t DestIPaddr;
  
  /* create new tcp pcb */
  echoclient_pcb = tcp_new();
  
  if (echoclient_pcb != NULL)
  {
    IP4_ADDR( &DestIPaddr, DEST_IP_ADDR0, DEST_IP_ADDR1, DEST_IP_ADDR2, DEST_IP_ADDR3 );
    
    /* connect to destination address/port */
    if(tcp_connect(echoclient_pcb,&DestIPaddr,0,tcp_echoclient_connected) == ERR_OK)
    	con = 1;
    else
    	
    	con = 0;
  }
}

2) При этом если я задаю не существующий DesrAddr также tcp_connect также возвращает ERR_OK

С одной стороны понятно что это функция возвращает успешно ли прошла передача запроса или нет,  но не понятно почему tcp_echoclient_connected в debug не возвращается

[HardEgor 140]

4 часа назад, addi II сказал:

посмотрел еще раз в дебаге, и два момента не понятны

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

[addi II 1]

6 minutes ago, HardEgor said:

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

выше я привел фукнцию 

void tcp_echoclient_connect(void)

в которой есть 

tcp_connect

в дебаге она возвращает ERR_OK, но при этом фактический параметр этой функции не исполняется 

tcp_echoclient_connected

В этом вопрос, почему не исполняется 

tcp_echoclient_connected

 

Edited September 20 by addi II

[HardEgor 140]

1 час назад, addi II сказал:

в дебаге она возвращает ERR_OK, но при этом фактический параметр этой функции не исполняется 

Честно говоря не уловил, как параметр должен исполнятся?