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/.
Andreas Schultz aschultz at tpip.netOn 11/04/2015 04:24 PM, Neels Hofmeyr wrote: > On 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. The above doesn't seem right. The specs say to send replies to the IP and port where the request originated. The GSN control plan address is only to be used when we want to send a request to the other side. So, shouldn't this work like this: * for each request, cache the source IP+Port and forward the reply back to that, * for each PDP context, remember the ctrl and data IP as requested by the GSN, forward requests to that I had some fun trying to understand how path management is supposed to work when control source IP != GSN control IP. I still don't get how the restart counter in the Recovery IE is supposed to be match to the GSN. > 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. That would apply to requests only, replies go back to the original source. Note: in GTPv2 this is getting even more complicated with triggered messages. > 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. Seems like the reasonable thing to do. > - 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). Replies should always go back to the request source IP. Only requests got to the GSN control plane IP. > 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 Lets hope all peers you are talking to are on the same IP version. Mixing IPv4 and IPv6 peer will be fun (see the Alternative GGSN Address). > Does that answer your question? > > And as always, please let me know if you find any dent in my reasoning :) I'm still trying to understand some of the finer points of GTP myself. - Andreas > > ~Neels