Click here to Skip to main content
15,867,765 members
Please Sign up or sign in to vote.
1.00/5 (1 vote)
See more:
The VLAN strip code for egress GTP packets results in source IP address ac150569 getting corrupted. After VLAN tag(4 bytes) is removed the source IP in the packet becomes ac150000 which is wrong.

Packet dump before VLAN tag is removed: 0ca402e8 deb15254 00b3fb19 81000873 08004500 002a00fc 00003e11 bf42ac15 05690a5f 00aa0868 08680016 001c3202 000600

Code for VLAN strip:
C++
memcpy( (rte_pktmbuf_mtod(m, unsigned char *)+12),
       ( rte_pktmbuf_mtod(m, unsigned char *)+16), m->pkt.data_len-16);
Packet dump after VLAN tag is removed: 0ca402e8 deb15254 00b3fb19 08004500 002a00fc 00003e11 bf42ac15 00000a5f 00aa0868 08680016 001c3202 1bdb0000 0000004e 00000e00

Can you please let me know how 0000 gets added in place of 0569 for source IP address in the modified packet after vlan tag is removed? What code changes needs to be done?

Thanks,

What I have tried:

C++
memcpy( (rte_pktmbuf_mtod(m, unsigned char *)+12),
        (rte_pktmbuf_mtod(m, unsigned char *)+16), m->pkt.data_len-16 );
m->pkt.data_len -= 4;
m->pkt.pkt_len -= 4;
Posted
Updated 14-Sep-18 4:51am
v2

1 solution

I find it helpful to expand the packet display and add offset labels to them:
81 00 08 73  08 00 45 00  00 2a 00 fc  00 00 3e 11  bf 42 ac 15  05 69 0a 5f  00 aa 08 68 
12 13 14 15  16 17 18 19  20 21 22 23  24 25 26 27  28 29 30 31  32 33 34 35  36 37 38 39

08 00 45 00  00 2a 00 fc  00 00 3e 11  bf 42 ac 15  00 00 0a 5f  00 aa 08 68  08 68 00 16
12 13 14 15  16 17 18 19  20 21 22 23  24 25 26 27  28 29 30 31  32 33 34 35  36 37 38 39
I see nothing in the code that would explain why two bytes of zeros are dropped into that sequence of bytes. It looks correct except for those two bytes. I would watch the data in the debugger and make sure that is what it looks like before and after the memcpy call. Look closely at the definition of the data packet structure and note where the data_len and pkt_len members are. It could be that the subtraction operation is clearing those bytes. Also verify what rte_pktmbuf_mtod does. If you just can't sort it out then you could save the address in a temporary variable before the memcpy call for use later.
 
Share this answer
 
v2
Comments
sarali 14-Sep-18 14:06pm    
Thanks for your inputs.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900