E810-CQDA2 - PPTP (GRE v1 / Protocol 47) traffic not passing through

[ShadowofReaosn]

Hi.

We have a couple of E810-CQDA2 network interfaces that we use for our uplink to our IP transit provider.
Everything works fine, except passing GRE v1 packets. 

We're currently running on the Debian 11.6 included ice driver with ddp ver 1.10.1.2.2
ethtool -i output:

driver: ice
version: 5.10.0-19-amd64
firmware-version: 2.50 0x800077a6 1.2960.0
expansion-rom-version: 
bus-info: 0000:03:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes

We've also tried the Intel official Linux driver, but no changes.

When we switch our uplink onto a X520-DA2 10Gbit card, then PPTP traffic is being forwarded again, so that assures that this is not a configuration/firewall issue.

Here's also a output of tcpdump of what's happening.
> 1.1.1.1 is the endpoint
> 2.2.2.2 is the initator

10:03:04.583817 IP 2.2.2.2.64899 > 1.1.1.1.1723: Flags [S], seq 152029234, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
10:03:04.583894 IP 1.1.1.1.1723 > 2.2.2.2.64899: Flags [S.], seq 2156739076, ack 152029235, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
10:03:04.589073 IP 2.2.2.2.64899 > 1.1.1.1.1723: Flags [.], ack 1, win 1026, length 0
10:03:04.589124 IP 2.2.2.2.64899 > 1.1.1.1.1723: Flags [P.], seq 1:157, ack 1, win 1026, length 156: pptp CTRL_MSGTYPE=SCCRQ PROTO_VER(1.0) FRAME_CAP(A) BEARER_CAP(A) MAX_CHAN(0) FIRM_REV(0) HOSTNAME() VENDOR(Microsoft)
10:03:04.589173 IP 1.1.1.1.1723 > 2.2.2.2.64899: Flags [.], ack 157, win 123, length 0
10:03:04.589653 IP 1.1.1.1.1723 > 2.2.2.2.64899: Flags [P.], seq 1:157, ack 157, win 123, length 156: pptp CTRL_MSGTYPE=SCCRP PROTO_VER(1.0) RESULT_CODE(1) ERR_CODE(0) FRAME_CAP(S) BEARER_CAP() MAX_CHAN(0) FIRM_REV(1) HOSTNAME(Mikrotik) VENDOR(MikroTik)
10:03:04.594449 IP 2.2.2.2.64899 > 1.1.1.1.1723: Flags [P.], seq 157:325, ack 157, win 1025, length 168: pptp CTRL_MSGTYPE=OCRQ CALL_ID(64899) CALL_SER_NUM(4) MIN_BPS(300) MAX_BPS(100000000) BEARER_TYPE(Any) FRAME_TYPE(E) RECV_WIN(64) PROC_DELAY(0) PHONE_NO_LEN(0) PHONE_NO() SUB_ADDR()
10:03:04.594702 IP 1.1.1.1.1723 > 2.2.2.2.64899: Flags [P.], seq 157:189, ack 325, win 131, length 32: pptp CTRL_MSGTYPE=OCRP CALL_ID(6) PEER_CALL_ID(64899) RESULT_CODE(1) ERR_CODE(0) CAUSE_CODE(0) CONN_SPEED(100000) RECV_WIN(100) PROC_DELAY(0) PHY_CHAN_ID(0)
10:03:04.600066 IP 2.2.2.2.64899 > 1.1.1.1.1723: Flags [P.], seq 325:349, ack 189, win 1025, length 24: pptp CTRL_MSGTYPE=SLI PEER_CALL_ID(6) SEND_ACCM(0xffffffff) RECV_ACCM(0xffffffff)
10:03:04.600196 IP 1.1.1.1.1723 > 2.2.2.2.64899: Flags [P.], seq 189:213, ack 349, win 131, length 24: pptp CTRL_MSGTYPE=SLI PEER_CALL_ID(64899) SEND_ACCM(0xffffffff) RECV_ACCM(0xffffffff)
10:03:04.657408 IP 2.2.2.2.64899 > 1.1.1.1.1723: Flags [.], ack 213, win 1025, length 0
10:03:05.551261 IP 1.1.1.1 > 2.2.2.2: GREv1, call 64899, seq 1, length 35: LCP, Conf-Request (0x01), id 1, length 21
10:03:06.632427 IP 1.1.1.1 > 2.2.2.2: GREv1, call 64899, seq 2, length 35: LCP, Conf-Request (0x01), id 2, length 21
10:03:08.144134 IP 1.1.1.1 > 2.2.2.2: GREv1, call 64899, seq 3, length 35: LCP, Conf-Request (0x01), id 3, length 21
10:03:10.236205 IP 1.1.1.1 > 2.2.2.2: GREv1, call 64899, seq 4, length 35: LCP, Conf-Request (0x01), id 4, length 21
10:03:13.629681 IP 1.1.1.1 > 2.2.2.2: GREv1, call 64899, seq 5, length 35: LCP, Conf-Request (0x01), id 5, length 21
10:03:18.965108 IP 1.1.1.1 > 2.2.2.2: GREv1, call 64899, seq 6, length 35: LCP, Conf-Request (0x01), id 6, length 21
10:03:26.913156 IP 1.1.1.1 > 2.2.2.2: GREv1, call 64899, seq 7, length 35: LCP, Conf-Request (0x01), id 7, length 21
10:03:36.933300 IP 1.1.1.1 > 2.2.2.2: GREv1, call 64899, seq 8, length 35: LCP, Conf-Request (0x01), id 8, length 21
10:03:41.931035 IP 2.2.2.2.64899 > 1.1.1.1.1723: Flags [P.], seq 349:365, ack 213, win 1025, length 16: pptp CTRL_MSGTYPE=CCRQ CALL_ID(64899)
10:03:41.931196 IP 1.1.1.1.1723 > 2.2.2.2.64899: Flags [F.], seq 213, ack 365, win 131, length 0
10:03:41.936365 IP 2.2.2.2.64899 > 1.1.1.1.1723: Flags [.], ack 214, win 1025, length 0

You can see that the GRE v1 LCP packet is being constantly retransmitted and the "rx_csum_bad.nic" value  under ethtool keeps raising by 1 per packet

I have seen a few posts about this issue, but no solution baked into the DDP package by Intel yet?
Please investigate this issue and publish a solution.

Thanks in advance.

Related posts:
Проблема с GRE(47) пакетами при прохождении через сетевой адаптер Intel E810-CQDA2 Ethernet 100Gb 2 
E810 Series GRE v1 Drop Issue [NVM Version 4.0] 

[Irwan_Intel]

Hello ShadowofReaosn,

Thank you for posting in Intel Ethernet Communities. 

I have escalated the question about DDP support for GRE v1 to our next level.

Meanwhile, for us to further check and investigate the issue, could you please provide some details:

1) What is the brand and model of your system board?

2) Debian 11.6 kernel version?

3) What is the PBA card number and serial number? You may provide photos of the NIC card on both sides, focusing on the markings.

4) When you switch to X520-DA2, do the driver and firmware remain the same?

Looking forward to your reply. In case there's no reply from you, I will follow up in 3 business days.

Regards,

Irwan_Intel

Intel Customer Support

[Irwan_Intel]

Hi ShadowofReaosn,

Have you try to load DDP COMMS package? GREv1 was fixed as part of DDP COMMS package.

Here is the download link for the DDP COMMS package https://www.intel.com/content/www/us/en/download/19660/intel-ethernet-800-series-dynamic-device-personalization-ddp-for-telecommunication-comms-package.html?wapkw=COMMS

Please let me know if you have further questions or concern.

Regards,

Irwan_Intel

Intel Customer Support

[ShadowofReaosn]

I will try loading the COMMS package, but due to these cards being currently commissioned, it will take about a week until I can test this.

Will keep this thread updated. 

[Irwan_Intel]

Hi ShadowofReaosn,

This is a follow up if you have further questions or concern regarding this issue.

Feel free to contact us should you need any further assistance, and we will be more than glad to continue assisting you.

Regards,

Irwan_Intel

Intel Customer Support

[Irwan_Intel]

Hi ShadowofReaosn,

I wanted to check in and ask if you have any additional questions or concerns that I can address for you?

Regards,

Irwan_Intel

Intel® Customer Support

[Irwan_Intel]

Hello ShadowofReaosn, 

I wanted to follow up and ask if there is anything else we can assist you with regarding your case. Please let us know if you have any further questions or concerns so we can help you further.

Regards,

Irwan_Intel

[Irwan_Intel]

Hi ShadowofReaosn,

Kindly note that as we have not received any response from our previous follow-ups, we will be closing this request. 

If you have any more questions in the future, please don't hesitate to post a new question, as this thread will no longer be monitored.

Regards,

Irwan_Intel