PPP on USB CDC

[biafra]

Hi everyone,

I'm working with MCUXpresso 10.2.1 and a custom build based on MK66FN180.

I've implemented the PPP protocol from LwIP library using a USB virtual COM: I can successfully connect with the device, setting up a TCP/IP socket and disconnect.

The problem is with a test session.

If the device sends a little packet (10/20) bytes) everything works fine, but if the packet is larger (~500 bytes) it doesn't work.

Searching for the reason of this behaviour, I changed the test: usigneg the command prompt I send the ping command with different packet sizes:

• ping -n 1 -l 16 130.100.100.100 (16 byte ping packet size)
• ping -n 1 -l 32 130.100.100.100 (32 byte ping packet size)

In the command prompt both the conditions run fine, but if I use an USB sniffer (Wireshark) I can see what is really happening:

This image shows the ICMP request packet of the first command: the ping packet is 16 bytes long, the application data section of the USB packet is 49 bytes long, the same length of the PPP packet.

This image shows the ICMP request packet of the second command: the ping packet is 32 bytes long, the application data section of the USB packet is 65 bytes long, the same length of the PPP packet.

Both the ping requests are embedded into a single USB packet sent from the host (the PC) to the device.

This image shows the ICMP reply packet of the first command: the ping packet is 16 bytes long, the application data section of the USB packet is 49 bytes long, the same length of the PPP packet.

This image shows the first portion of the ICMP reply packet of the second command: the ping packet is 32 bytes long, the application data section of the USB packet is 64 bytes long, a different length than the PPP packet, that is 65 bytes long. The last byte of the PPP packet is missing.

This image shows the final portion of the ICMP reply packet of the second command: the application data section of the USB packet is 1 byte long, the missing byte of the previous packet.

As you can see, if the application has to send more than 64 data bytes, thay are splitted in separate USB packets with a maximum length of 64 byte.

If the ping packet length is still small, the ping test seems to continue to work fine, even if there are the problems seen with Wireshark. But if the ping packet length becomes greater, using the command ping -n 1 -l 160 130.100.100.100 (160 byte ping packet size), the ping test fails.

I think this is the reason for the initial test not working.

I think that the limit of 64 byte come from the macro:

#define FS_CDC_VCOM_BULK_OUT_PACKET_SIZE ( 64 )

Can I increase this value?

How can I handle this situation?

Many thanks

Biafra

[FelipeGarcia]

Hi Bifra,

The maximum packet size for bulk transfers in Full Speed USB is 64 bytes as shown in the FS_CDC_VCOM_BULK_OUT_PACKET_SIZE macro.

However, K66 MCU supports High Speed USB which maximum packet size is 512 bytes. You could try switching the VCOM example to High speed and check your results.

I hope you find this helpful.

Have a great day,
Felipe

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[biafra]

Hi Felipe,

Many thanks for your suggestion, but there are two problems:

• The board is already done and the USB controller is USB0 and it can work only at Full Speed
• Since the application runs with TCP/IP over PPP on the USB connection, I need to send a TCP packet, that can have a size over 1500 bytes, so even the High Speed packet size of 512 bytes is not enough

There is another way?

Many thanks

Biafra

[FelipeGarcia]

Hi Biafra,

The maximum packet size is established by the USB specification so we cannot modify that number.

The USB VCOM CDC example manages to split the packet in 64 bytes packets at full speed. You shouldn't have any problems in the USB side.

According how the USB system works, each packet is sent as a transfer, a series of maximum-length (64 bytes in full speed) packets terminated by a short packet or a special ZLP (zero-length packet).

I assume you issue is regarding how you implemented your PPP protocol.

Best regards,

Felipe

[biafra]

Hi Felipe,

The PPP protocol implementation is the LwIP one: when there is a PPP packet to send the USB_Send() function is called, the parameters are the PPP packet and the PPP length. The USB driver correctly splits the packet as needed and it sends it, as you can see in the images above.

The problem is that all the splitted packets except the first one are recognized as malformed packets.

Many thanks

Biafra

[FelipeGarcia]

Hi Biafra,

If you are willing to share your code I could take a quick look. In case I find something I will let you know.

Best regards,

Felipe

[biafra]

Hi Felipe,

I will share the USB driver and the PPP parser.

Many thanks

Biafra