Hi Neels and Pablo, first of all, it is great to see this code appear, I never liked libgtp much either... On Thu, Oct 15, 2015 at 03:32:02PM +0200, Neels Hofmeyr wrote:
+struct gtp0_header { +#if BYTE_ORDER == BIG_ENDIAN + uint8_t version:3, + pt:1, + spare:3, + snn:1; +#elif BYTE_ORDER == LITTLE_ENDIAN + uint8_t snn:1, + spare:3, + pt:1, + version:3;
Hmm, endianness is about *byte* order, not *bit* order, right?
Life would be too simple for that. It there is both byte-endinanness and bit-endianness. And if you define bit-fields using the c syntax, then (at least on all platforms I know), you have to split your definition like above. Look at the definitions of IP header and TCP header in your /usr/include/netinet/ip.h or /usr/include/netinet/tcp.h
to use one of the existing decoding functions for endianness instead: - ntohs()/ntohl()
that doesn't help you with what pablo defined, as it is about an uint8_t ;)
+ gtp0h->seq = htons(seq); + gtp0h->tid = htobe64(tid);
Ah, here it is: htons() stored in the header struct. I'd prefer a host-byte-order struct.
The struct itself (for 16bit/32bit members of the struct) dosen't care. And the function you refer to takes host-byte-order input and then pushes the values as network byte ordre to the msgb, which I think is fine.
+void gtp0_header_end(struct gtp0_header *gtp0h, struct msgb *msg) +{ + gtp0h->length = htons(msg->len - sizeof(*gtp0h));
With msgb_alloc_headroom(), it is possible to first write the IEs to the msgb, and then prepend the header with the correct size later on. See for example in openbsc, gprs_gsup_msgb_alloc() and ipa_msg_push_header().
yes, that is the preferred method.
+static const struct tlv_definition gtp_pdp_create_req_attr_tlvdef = { + .def = { + [GTPV0_IE_QOS_PROFILE] = { TLV_TYPE_FIXED, 3 }, +};
I can't begin to express how much better this looks than the old gtpie.h!
Well, that's how we generaly deal with TLVs in libosmocore based programs :)
+void *msgb_tv_put_be24(struct msgb *msg, int type, uint32_t value) +{ + value = htonl(value & 0x00ffffff) >> 8;
heh, interesting :) This won't work on a BE system. You can't portably do a host CPU shift-right on a network byte order value.
On a BE system the htonl() will evaporate and you end up with doning only a shift-right by 8, which is probably not what you wanted, indeed.
Imagining a class: Big Endian 101, Professor asks: "Can anyone explain the results of this code on a big endian and a little endian system?" Half an hour of vigorous discussion follows.
Beware, Pablo is a CS Professor at Sevilla University ;) -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)