Actions
Bug #1879
closedreserved bit in GTPv1 header set wrong
Start date:
12/15/2016
Due date:
% Done:
100%
Spec Reference:
Description
Three is a "reserved" bit in the flags octet of the GTPv1 header.
The existing Linux Kernel GTP code in gtp1_push_header() sets it to '1', which is wrong:
- Wikipedia states: bit4=res, shall be 0
- 29.060 v3.19.0 rel 99: bit456=res, shall be 0
- 29.060 v6.9.0 rel 6: bit4=reserved, shall be 0
- 29.060 v12.6.0 rel 12: bit4=reserved, shall be 0
as wikipedia and three versions accross all releases state the bit shall be '0', it is a good idea to set it zero.
Going back to Release 98, though, the 'reserved' bit and the 'extension header' and 'sequence number' bit are supposed to be set all to one:
- 09.60 v7.9.0 rel 98: bit456=res, all 1
- 09.60 v7.10.0 rel 98: bit456=res, all 1
But that is GTPv0, which we handle (correctly) in gtp0_push_header().
Files
Related issues
Updated by laforge over 7 years ago
- File 0001-GTP-Fix-initialization-of-Flags-octet-in-GTPv1-heade.patch 0001-GTP-Fix-initialization-of-Flags-octet-in-GTPv1-heade.patch added
- % Done changed from 0 to 80
attaching a trivial patch for the seemingly trivial problem. However, not tested yet, let's not rush this.
Updated by laforge over 7 years ago
- Related to Bug #1880: handling of reserved bit in flag octet broken added
Updated by laforge over 7 years ago
- Related to Feature #1621: test + document OpenGGSN with osmo-gtp-kernel code added
Updated by laforge over 7 years ago
- Status changed from New to Resolved
- % Done changed from 80 to 100
patch has been submitted to DaveM for mainline inclusion, see http://www.spinics.net/lists/netdev/msg410548.html
Actions