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.deOn Wed, Nov 04, 2015 at 10:20:45AM +0100, Andreas Schultz wrote: > Hi Neels, > > I'm trying to understand how you handle a PDP Create Context message where > the SGSN Address for control plane and an SGSN address for user traffic differ > from the sender IP? That part is ultimately still missing, as may be visible from the PDP Context unit test. So far it's recording only the actual originating address as returned by the socket read. It's my plan for today. But the internal storage is ready. gtphub will examine the IEs SGSN Address for signalling SGSN Address for user traffic and GGSN Address for Control Plane GGSN Address for user traffic and store these addresses for future use. The addresses are stored separately, with association pointers from one to the other. There's a bit of a handwavy situation there, e.g. if an SGSN sends a PDP Create request from 1.2.3.4, but the address in the IE is 5.6.7.8. gtphub later on needs to find the proper peer record; if I stored a peer for 5.6.7.8 and the SGSN again were to send from 1.2.3.4, gtphub would not be able to match that up. I will so far only store the IE's address (5.6.7.8), and expect the SGSN to continue sending ctrl messages for this PDP context from 5.6.7.8 from then on. After all that's what it told me to use. The user plane is not affected, because the only place to find the user address is in the IE from a Create PDP Context message, sent on the ctrl plane, so there's no mismatch situation arising. If any GSN in practice actually wanted to send all ctrl messages from 1.2.3.4 but expected the returned ctrl responses to come back on 5.6.7.8, then gtphub would have to store the sender's address 1.2.3.4 as well. Concerning the ports, we've discussed before that the proper way according to spec is to always use the standard port number for the respective plane when sending out a packet to a peer. gtphub can manage both (sender's port or override with standard port), but when the IE's address mismatches the sender's address, and if I henceforth want use the IE's address, I have no port information for that one (see 7.7.32 in 29.060 and 5.1 in 23.003). The sender's port is actually not relevant at all, so I will semantically have to use the default port number. gtphub would also be able to manage "return to sender", if that's what we need (that's what it's doing now, preliminarily). Thinkable configs: - Use exclusively the address from the IEs. - Disallow mismatch of CTRL sender and address in CTRL IE. - When addresses match, use sender's port (ugly, but OpenGGSN seems to use the sender's port, so maybe there's something to it; yet I don't trust OpenGGSN by now). I'm handling IPv4 and v6 transparently, BTW. The difference in the IE is only detectable from the IE length, as 7.7.32 doesn't include the GSN address' type field. Let's hope IPv8 will have the same length as IPv6 :P Does that answer your question? And as always, please let me know if you find any dent in my reasoning :) ~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/20151104/069fd1e7/attachment.bin>