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/osmocom-commitlog@lists.osmocom.org/.
gitosis at osmocom.org gitosis at osmocom.orgThis is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The OpenBSC GSM Base Station Controller (+MSC/HLR/SGSN)". The branch, zecke/features/auth has been created at 393b605c1a0d747a4c36eca91aa48e9475c171ee (commit) - Log ----------------------------------------------------------------- http://cgit.osmocom.org/openbsc/commit/?id=393b605c1a0d747a4c36eca91aa48e9475c171ee commit 393b605c1a0d747a4c36eca91aa48e9475c171ee Author: Holger Hans Peter Freyther <holger at moiji-mobile.com> Date: Mon Jun 8 18:33:28 2015 +0200 nat: After we identified the bsc check the key We are using the token to find the right bsc_config and then we can use the last_rand of the bsc_connection to calculate the expected result and try to compare it with a time constant(???) memcmp. http://cgit.osmocom.org/openbsc/commit/?id=f6ff44c023c93778f68bed67cc93253e31106d0d commit f6ff44c023c93778f68bed67cc93253e31106d0d Author: Holger Hans Peter Freyther <holger at moiji-mobile.com> Date: Mon Jun 8 18:02:10 2015 +0200 bsc: Check for the rand and then generate a res Check if the NAT has sent 16 bytes of RAND and if a key has been configured in the system and then generate a result using milenage. The milenage res will be sent and noth the four byte GSM SRES derivation. http://cgit.osmocom.org/openbsc/commit/?id=8885ce001fbf3bfe659f361c901014b41e4428db commit 8885ce001fbf3bfe659f361c901014b41e4428db Author: Holger Hans Peter Freyther <holger at moiji-mobile.com> Date: Mon Jun 8 16:28:15 2015 +0200 nat: Send 16 bytes of rand to the BSC and remember it Generate 16 byte of random data to be used for A3A8 by the BSC in the response. We can't know which BSC it is at this point and I don't want to send another message once the token has been received so always send the data with an undefined code. The old BSCs don't parse the message and will happily ignore the RAND. /dev/urandom can give short reads on Linux so loop around it until the bytes have been read from the kernel. http://cgit.osmocom.org/openbsc/commit/?id=7b608771dd1d4ded5ebf576b1462a0c12452f0fe commit 7b608771dd1d4ded5ebf576b1462a0c12452f0fe Author: Holger Hans Peter Freyther <holger at moiji-mobile.com> Date: Mon Jun 8 11:56:59 2015 +0200 nat: Provide access to /dev/urandom for the code Instead of doing open/read/close all the time, open the FD in the beginning and keep it open. To scare me even more I have seen /dev/urandom actually providing a short read and then blocking but it seems to be the best way to get the random byes we need for authentication. So one should/could run the cheap random generator on the system (e.g. haveged) or deal with the NAT process to block. http://cgit.osmocom.org/openbsc/commit/?id=ad46558c54c3de17af2df2ccae46361cb7743332 commit ad46558c54c3de17af2df2ccae46361cb7743332 Author: Holger Hans Peter Freyther <holger at moiji-mobile.com> Date: Wed Jun 10 11:51:16 2015 +0200 bsc/nat: Fix the structure of the identity request message Unfortunately the basic structure of the response is broken. There is a two byte length followed by data. The concept of a 'tag' happens to be the first byte of the data. This means we want to write strlen of the token, then we want to write the NUL and then we need to account for the tag in front. Introduce a flag if the new or old format should be used. This will allow to have new BSCs talk to old NATs without an additional change. In the long run we can clean that up. http://cgit.osmocom.org/openbsc/commit/?id=fc9a3ff9dc3801c4ec6927cc80ec2625d1332d65 commit fc9a3ff9dc3801c4ec6927cc80ec2625d1332d65 Author: Holger Hans Peter Freyther <holger at moiji-mobile.com> Date: Mon Jun 8 11:55:02 2015 +0200 nat: Close the connection after we couldn't find the user In case the token was not correct, just close the connection. It is not clear that forcing a new TCP connection is going to give us any extra security here. But with the upcoming auth handling it does make sense to have both case look similar. http://cgit.osmocom.org/openbsc/commit/?id=08ff087c9989822d2b0fe344264b95d0343b6676 commit 08ff087c9989822d2b0fe344264b95d0343b6676 Author: Holger Hans Peter Freyther <holger at moiji-mobile.com> Date: Mon Jun 8 09:54:45 2015 +0200 nat: Factor out the config by token search In the upcoming authentication improvements it is nice to separate the finding of the config from the post-allow handling of it. http://cgit.osmocom.org/openbsc/commit/?id=3d07ca5e2f23bc86b9f938efd93ef3331ddc41cd commit 3d07ca5e2f23bc86b9f938efd93ef3331ddc41cd Author: Holger Hans Peter Freyther <holger at moiji-mobile.com> Date: Mon Jun 8 18:31:02 2015 +0200 nat: Add size check for the payload The msgb will always have these bytes but it is better practice to verify that the message really has space for the two bytes. ----------------------------------------------------------------------- hooks/post-receive -- The OpenBSC GSM Base Station Controller (+MSC/HLR/SGSN)