Ethernet over USB

Если вы генерируете проект с LWIP из Cube MX на контроллере с аппаратной встроенной поддержкой Ethernet, то куб сделает примерно такой шаблон программы :

После инициализации всей периферии в цикле вызываем MX_LWIP_Process :

MX_LWIP_Process
   ethernetif_input //  
       low_level_input  // move received packet into a new pbuf
          HAL_ETH_GetReceivedFrame
          pbuf * p = pbuf_alloc 
          // выделяем буфер для приема поступивших байт
          memcpy
          // копируем в наш буфер
          return p 
         // возвращаем указатель на буфер памяти , куда приняли байты
sys_check_timeouts();

Эмуляция Ethernet через USB канал (RNDIS адаптер)

Тут суть та же самая , но подменяется канал : вместо Ethernet будет USB :

В цикле вызываем usb_polling , как в примере Сергея Фетисова.

void usb_polling()
{

	struct pbuf *frame;

	__disable_irq();

	if (receivedFromUSBSize == 0)
	{
		__enable_irq();
		return;
	}

	frame = pbuf_alloc(PBUF_RAW , receivedFromUSBSize , PBUF_POOL);

	if (frame == NULL)
	{
		__enable_irq();
		return;
	}

	memcpy(frame->payload, receivedFromUSB, receivedFromUSBSize);

	frame->len = receivedFromUSBSize;

	receivedFromUSBSize = 0;

	__enable_irq();

	ethernet_input(frame, &netif_data);

	pbuf_free(frame);
}

И вот прием пакетов с ПК в STM32 пошел, а ответа в ПК нет ....

ethernet_input
etharp_arp_input
netif->linkoutput(netif, p); // return ARP reply
/* This function is called by the ARP module when it wants
* to send a packet on the interface. This function outputs
* the pbuf as-is on the link medium. */

linkoutput это часть struct netif , а именно указатель на функцию коллбек, которую надо написать самим. Понятно она должна перенаправлять ответ на USB канал.

И тут проблем не возникает.

Но вот , что на самом деле нехорошо - это то ,что похоже в LWIP (даже полследней версии 1.2.1) есть только реализация только DHCP клиента, а он нам вообще-то не нужен, т.к. наш RNDIS адатор сам должен быть DHCP сервером.