KCM to parse / de-multiplex IPA in kernel?

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Neels Hofmeyr nhofmeyr at sysmocom.de
Mon Sep 28 12:58:03 UTC 2015


On Fri, Sep 25, 2015 at 09:13:01AM +0200, Harald Welte wrote:
> Hi all,
> 
> it seems like there is some work in the kernel network stack to have a
> generic multiplexor/demultiplexor for protocols that implement
> message-based semantics over TCP:
> 	http://thread.gmane.org/gmane.linux.network/378365
> 
> They don't implement a specific messaging protocol, but the userspace
> program can  BPF to let the kernel muxer know how to find the length
> of the message.
> 
> This seems like conceptually it is suitable for actually implementing an
> IPA multiplex inside the kernel and then get e.g. Abis OML and RSL on
> different sockets.

Interesting, as my recent patch submission does some effort to multiplex
the SGSN<->MAP IPA wire to GSUP and the new OAP. The difference between
the two is visible from the proto_ext byte, easy to filter on.

So IIUC with (e)BPF in the kernel, we can load two eBPF programs on an IPA
socket and somehow get two separate sockets(?) to read from, where each
will yield only those IPA packets that match the respective proto_ext.
There is also the connection housekeeping (IPA ping/pong and so on), which
is independent of the IPA proto payload. Could be a third eBPF program &
socket (or the like) ... ?  Interesting in the sense: "You want another
proto on your IPA wire? just open another BPF without changing the current
IPA code."

But so far it sounds like the BPF can only examine and maybe drop packets
on a single socket and not yet mux towards multiple readers (we can add a
BPF sockopt on one socket, not get N sockets, AFAICT).

And, when muxing is already working in internal code, replacing that with
BPF is just more work, of course.

But will keep in mind for the future, I guess :)

~Neels

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20150928/b41760a0/attachment.bin>


More information about the OpenBSC mailing list