openLTE / Discussion / General Discussion: Security Mode Issue with 18.3

David Lake - 2015-02-19

Ben

Just tested 18.3 - the RNTI allocation is certainly MUCH more stable now.

But, I'm hitting a hurdle with registration. None of my UEs which would previously work intermittently on 18.2 will register.

I'm seeing this in the log file:

2/18/2015 20:47:55.522450 info rrc LTE_fdd_enb_rrc.cc 592 Received UL Information Transfer for RNTI=61, RB=SRB1
2/18/2015 20:47:55.522519 info mme LTE_fdd_enb_mme.cc 200 Received NAS message for RNTI=61 and RB=SRB1 075F18
2/18/2015 20:47:55.522547 info mme LTE_fdd_enb_mme.cc 931 Received Security Mode Reject for RNTI=61 and RB=SRB1
2/18/2015 20:47:55.522571 error mme LTE_fdd_enb_mme.cc 942 Security Mode Rejected cause=18, RNTI=61, RB=SRB1
2/18/2015 20:47:55.522580 info rb LTE_fdd_enb_rb.cc 243 SRB1 MME state moving from ENABLE SECURITY to RELEASE for RNTI=61

I get a user authentication and everything seem to be fine including EPS attach:

2/18/2015 20:47:55.322975 info mme LTE_fdd_enb_mme.cc 747 Authentication successful for RNTI=61 and RB=SRB1
2/18/2015 20:47:55.322988 info rb LTE_fdd_enb_rb.cc 243 SRB1 MME state moving from AUTHENTICATE to ENABLE SECURITY for RNTI=61
2/18/2015 20:47:55.323013 info mme LTE_fdd_enb_mme.cc 1614 Sending Security Mode Command for RNTI=61, RB=SRB1 373D6BE03900075D020004E060C040C1

I go around and around and never actually attach succesfully.

Did something else change that I haven't worked out ?

This is with my Huawei data stick which authenticate sometimes on 18.2

Thanks

David

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- bwojtowi - 2015-02-20
  
  David,
  
  Thanks for the quick response with initial test results! Not much changed
  from the MME perspective, so I'm not sure what is going on. Can you
  provide the LTE PCAP capture from this?
  
  Also, I am very interested in your test results using the GPSDO. I am
  still seeing issues with end-to-end IP packets and it appears to me to be
  timing. However, it's hard to find concrete evidence of this.
  Specifically, can you look at how many times your UE re-RACHs for the same
  connection? Mine will re-RACH approximately every 2 seconds.
  
  Thanks,
  Ben
  
  On Wed, Feb 18, 2015 at 11:11 PM, David Lake dlake02@users.sf.net wrote:
  
  Ben
  
  Just tested 18.3 - the RNTI allocation is certainly MUCH more stable now.
  
  But, I'm hitting a hurdle with registration. None of my UEs which would
  previously work intermittently on 18.2 will register.
  
  I'm seeing this in the log file:
  
  2/18/2015 20:47:55.522450 info rrc LTE_fdd_enb_rrc.cc 592 Received UL
  Information Transfer for RNTI=61, RB=SRB1
  2/18/2015 20:47:55.522519 info mme LTE_fdd_enb_mme.cc 200 Received NAS
  message for RNTI=61 and RB=SRB1 075F18
  2/18/2015 20:47:55.522547 info mme LTE_fdd_enb_mme.cc 931 Received
  Security Mode Reject for RNTI=61 and RB=SRB1
  2/18/2015 20:47:55.522571 error mme LTE_fdd_enb_mme.cc 942 Security Mode
  Rejected cause=18, RNTI=61, RB=SRB1
  2/18/2015 20:47:55.522580 info rb LTE_fdd_enb_rb.cc 243 SRB1 MME state
  moving from ENABLE SECURITY to RELEASE for RNTI=61
  
  I get a user authentication and everything seem to be fine including EPS
  attach:
  
  2/18/2015 20:47:55.322975 info mme LTE_fdd_enb_mme.cc 747 Authentication
  successful for RNTI=61 and RB=SRB1
  2/18/2015 20:47:55.322988 info rb LTE_fdd_enb_rb.cc 243 SRB1 MME state
  moving from AUTHENTICATE to ENABLE SECURITY for RNTI=61
  2/18/2015 20:47:55.323013 info mme LTE_fdd_enb_mme.cc 1614 Sending
  Security Mode Command for RNTI=61, RB=SRB1 373D6BE03900075D020004E060C040C1
  
  I go around and around and never actually attach succesfully.
  
  Did something else change that I haven't worked out ?
  
  This is with my Huawei data stick which authenticate sometimes on 18.2
  
  Thanks
  
  David
  
  Security Mode Issue with 18.3
  https://sourceforge.net/p/openlte/discussion/general/thread/162b15e6/?limit=25#fd40
  
  Sent from sourceforge.net because you indicated interest in
  https://sourceforge.net/p/openlte/discussion/general/
  
  To unsubscribe from further messages, please visit
  https://sourceforge.net/auth/subscriptions/
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - David Lake - 2015-02-20
    
    Hi Ben
    
    I'll work on the PCAP tomorrow when I get a chance. I've got a deadline on a dissertation coming up and I'm.... errrr... a little late :-)
    
    Until I can get either of my UEs to register and attach fully, testing the end-to-end is going to be a difficult. But I have noticed that without the GPSDO, even scanning for the network is flaky but rock-solid WTIH the GPSDO.
    
    Couple of weird other things I'm seeing on 18.3:
    
    1) "2/18/2015 19:47:45.776965 error mac LTE_fdd_enb_mac.cc 355 RTS ul_current_tti incorrect: RTS 1 but currently on 0"
    
    Happens at start-up every time before the RX Sync (but I looked through the code and it looks like you jump forward to match the timeslots, so no big deal)
    
    2) When things DO fail, I see this error message repeated over and over (with incrementing MAC and PHY timeslots)
    
    "2/18/2015 19:49:01.360762 error phy LTE_fdd_enb_phy.cc 645 PDSCH current_tti from MAC (2898) does not match PHY (2908)"
    
    Trace with you as soon as I can.
    
    David
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - David Lake - 2015-02-20
    
    FINALLY managed to get a pcap with the Security Mode Reject from the UE.
    
    Packet number 56 is the UL-DCCH Reject.
    
    David
    
    C:\Users\dlake.CISCO\Documents\products\LTE\OpenLTE\20-Feb\LTE_fdd_enodeb.pcap
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
    - David Lake - 2015-02-20
      
      Ben
      
      This might be totally unrelated, but take a look at packet 9 (EPS attach) and packet 45 (Security Mode Command).
      
      Reading http://howltestuffworks.blogspot.com/2011/11/nas-security-mode-reject.html seems to indicate that if the UE Security Capabilities don't match in the inital attach and the replay in the Security Mode, then the UE will reject the Security Mode command.
      
      They don't match. The UE Network Capabilitiy in the EPS Attach is:
      
      04 E0 60 c0 c0
      
      The Replayed UE Security is
      
      04 E0 60 c0 40
      
      Clutching at straws here !
      
      David
      
      If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
      - bwojtowi - 2015-02-21
        
        David,
        
        I'll have to dig into this one more, but I'm at somewhat of a loss. If the
        UE didn't like the replayed UE security capabilities, it would have
        signalled that with the EMM cause in the security mode reject (cause 23).
        The one bit difference between the two is the UCS2 flag which is present in
        UE network capabilities but not in UE security capabilities.
        
        Thanks,
        Ben
        
        On Fri, Feb 20, 2015 at 4:48 PM, David Lake dlake02@users.sf.net wrote:
        
        Ben
        
        This might be totally unrelated, but take a look at packet 9 (EPS attach)
        and packet 45 (Security Mode Command).
        
        Reading
        http://howltestuffworks.blogspot.com/2011/11/nas-security-mode-reject.html
        seems to indicate that if the UE Security Capabilities don't match in the
        inital attach and the replay in the Security Mode, then the UE will reject
        the Security Mode command.
        
        They don't match. The UE Network Capabilitiy in the EPS Attach is:
        
        04 E0 60 c0 c0
        
        The Replayed UE Security is
        
        04 E0 60 c0 40
        
        Clutching at straws here !
        
        David
        
        Security Mode Issue with 18.3
        https://sourceforge.net/p/openlte/discussion/general/thread/162b15e6/?limit=25#fd40/d23e/10a8/8e94
        
        Sent from sourceforge.net because you indicated interest in
        https://sourceforge.net/p/openlte/discussion/general/
        
        To unsubscribe from further messages, please visit
        https://sourceforge.net/auth/subscriptions/
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
        
        David Lake - 2015-02-21
        
        I'm concerned this may be due to a failure on my USIM - I'm using the Green-Card SIM and I don't have 100% confidence in them....
        
        The original USIMs are now in stock again at Syscomm - I need some for another project so I've ordered them. Going to take some days to get them.
        
        David
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

David Lake - 2015-02-20

Ben

Got a problem here where my UE won't even try and attach.

The issue seems to be that the eNodeB gets into an error state when the UE first RACHs and never recovers. Trace attached.

David

C:\Users\dlake.CISCO\Documents\products\LTE\OpenLTE\06_Feb\FEB_20_trace2

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- bwojtowi - 2015-02-21
  
  David,
  
  It looks like there may be some issues with the RTS timing still. I'll dig
  into this more and see if I can reproduce the issue.
  
  Thanks,
  Ben
  
  On Fri, Feb 20, 2015 at 12:40 PM, David Lake dlake02@users.sf.net wrote:
  
  Ben
  
  Got a problem here where my UE won't even try and attach.
  
  The issue seems to be that the eNodeB gets into an error state when the UE
  first RACHs and never recovers. Trace attached.
  
  David
  
  Attachment:
  C:\Users\dlake.CISCO\Documents\products\LTE\OpenLTE\06_Feb\FEB_20_trace2
  (2.5 MB; text/plain)
  
  Security Mode Issue with 18.3
  https://sourceforge.net/p/openlte/discussion/general/thread/162b15e6/?limit=25#9b99
  
  Sent from sourceforge.net because you indicated interest in
  https://sourceforge.net/p/openlte/discussion/general/
  
  To unsubscribe from further messages, please visit
  https://sourceforge.net/auth/subscriptions/
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - David Lake - 2015-02-27
    
    Ben
    
    I'm rapidly coming to the conclusion that the GRCard is not running the Milenage algorithm correctly - hence the "24" error.
    
    I've got some new cards on order and I'm trying to make PySim work properly so that I can take a look at the card provisioning. It's a whole new area for me, so I need to learn very fast and may take me a while to understand.
    
    Let me know when you have the RTS worked out - I can run up a test in a matter of hours.
    
    David
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

David Lake - 2015-02-28

Ben - confirmed; the programming of the new Grcards is NOT intuative, and I'd got it wrong.

I've now re-programmed and been able to succesfully attach/authenticate, but only once due to the RTS issue. 9 times out of 10, I get into the PDSCH loop as above.

Thank you again for your work on this.

David

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Tony - 2015-03-09

Hi David,
Can your UEs connet to the enobeb for surfing the Internet (like Google)?

Tony

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

David Lake - 2015-03-09

No. Ben mentioned that there are RTS timing issues. This will scupper everything until those are fixed.

David

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- bwojtowi - 2015-03-12
  
  David,
  
  Can you document the procedure for getting the Grcards to work and send it
  to Csaba for inclusion into the wiki?
  
  Also, regarding the RTS timing, it is now fixed in the latest release
  (00.18.04).
  
  Thanks,
  Ben
  
  On Mon, Mar 9, 2015 at 10:14 AM, David Lake dlake02@users.sf.net wrote:
  
  No. Ben mentioned that there are RTS timing issues. This will scupper
  everything until those are fixed.
  
  David
  
  Security Mode Issue with 18.3
  https://sourceforge.net/p/openlte/discussion/general/thread/162b15e6/?limit=25#651c
  
  Sent from sourceforge.net because you indicated interest in
  https://sourceforge.net/p/openlte/discussion/general/
  
  To unsubscribe from further messages, please visit
  https://sourceforge.net/auth/subscriptions/
  
  alternate
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - David Lake - 2015-03-13
    
    Ben
    
    I'll work on the Wiki entry - the new GRCards are NOT supported by pysim, so it is a two-step approach of generating the OPc with PySIm and then writing with the Windows software that grcard.cn provides. Not neat !
    
    I'll run-up 0.18.04 over the weekend and see how it looks !! THANK YOU !
    
    David
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

David Lake - 2015-03-14

Hi Ben

18.4 not working for me.

I can see the network and try to attach, but the UE times-out. I do see a succesful "authenticate" but never go any further than that.

When I telnet to the debug port, I see this constantly from when the eNB starts:

03/13/2015 17:15:46.144492 error phy LTE_fdd_enb_phy.cc 646 PDSCH current_tti from MAC (8835) does not match PHY (615)
03/13/2015 17:15:46.145553 error phy LTE_fdd_enb_phy.cc 646 PDSCH current_tti from MAC (8836) does not match PHY (616)
03/13/2015 17:15:46.146485 error phy LTE_fdd_enb_phy.cc 646 PDSCH current_tti from MAC (8827) does not match PHY (617)
03/13/2015 17:15:46.147550 error phy LTE_fdd_enb_phy.cc 646 PDSCH current_tti from MAC (8828) does not match PHY (618)
03/13/2015 17:15:46.148482 error phy LTE_fdd_enb_phy.cc 646 PDSCH current_tti from MAC (8829) does not match PHY (619)
03/13/2015 17:15:46.149552 error phy LTE_fdd_enb_phy.cc 646 PDSCH current_tti from MAC (8830) does not match PHY (620)
03/13/2015 17:15:46.150478 error phy LTE_fdd_enb_phy.cc 646 PDSCH current_tti from MAC (8831) does not match PHY (621)
03/13/2015 17:15:46.151542 error phy LTE_fdd_enb_phy.cc 646 PDSCH current_tti from MAC (8832) does not match PHY (622)
03/13/2015 17:15:46.152474 error phy LTE_fdd_enb_phy.cc 646 PDSCH current_tti from MAC (8833) does not match PHY (623)
03/13/2015 17:15:46.153655 error phy LTE_fdd_enb_phy.cc 646 PDSCH current_tti from MAC (8834) does not match PHY (624)
03/13/2015 17:15:46.154477 error phy LTE_fdd_enb_phy.cc 646 PDSCH current_tti from MAC (8835) does not match PHY (625)
03/13/2015 17:15:46.155534 error phy LTE_fdd_enb_phy.cc 646 PDSCH current_tti from MAC (8836) does not match PHY (626)
03/13/2015 17:15:46.156468 error phy LTE_fdd_enb_phy.cc 646 PDSCH current_tti from MAC (8827) does not match PHY (627)
03/13/2015 17:15:46.157530 error phy LTE_fdd_enb_phy.cc 646 PDSCH current_tti from MAC (8828) does not match PHY (628)
03/13/2015 17:15:46.158595 error phy LTE_fdd_enb_phy.cc 646 PDSCH current_tti from MAC (8829) does not match PHY (629)
03/13/2015 17:15:46.159533 error phy LTE_fdd_enb_phy.cc 646 PDSCH current_tti from MAC (8830) does not match PHY (630)
03/13/2015 17:15:46.160590 error phy LTE_fdd_enb_phy.cc 646 PDSCH current_tti from MAC (8831) does not match PHY (631)
03/13/2015 17:15:46.161522 error phy LTE_fdd_enb_phy.cc 646 PDSCH current_tti from MAC (8832) does not match PHY (632)
03/13/2015 17:15:46.162587 error phy LTE_fdd_enb_phy.cc 646 PDSCH current_tti from MAC (8833) does not match PHY (633)
03/13/2015 17:15:46.163519 error phy LTE_fdd_enb_phy.cc 646 PDSCH current_tti from MAC (8834) does not match PHY (634)
03/13/2015 17:15:46.164586 error phy LTE_fdd_enb_phy.cc 646 PDSCH current_tti from MAC (8835) does not match PHY (635)
03/13/2015 17:15:46.165515 error phy LTE_fdd_enb_phy.cc 646 PDSCH current_tti from MAC (8836) does not match PHY (636)
03/13/2015 17:15:46.166579 error phy LTE_fdd_enb_phy.cc 646 PDSCH current_tti from MAC (8827) does not match PHY (637)
03/13/2015 17:15:46.167511 error phy LTE_fdd_enb_phy.cc 646 PDSCH current_tti from MAC (8828) does not match PHY (638)
03/13/2015 17:15:46.168575 error phy LTE_fdd_enb_phy.cc 646 PDSCH current_tti from MAC (8829) does not match PHY (639)

Thanks

David

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- David Lake - 2015-03-14
  
  Slightly incorrect. If I turnn OFF debugging, then the UE does attach. But the throughput is very, very slow (3-4 seconds between pings) suggesting that all I am doing by turning the debugging off is masking the problem....
  
  David
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - bwojtowi - 2015-03-22
    
    David,
    
    Thanks for the feedback. Looks like the RTS issue isn't completely dead.
    I'll take a look and see if I can make some fixes in the next release.
    
    Thanks,
    Ben
    
    On Fri, Mar 13, 2015 at 5:40 PM, David Lake dlake02@users.sf.net wrote:
    
    Slightly incorrect. If I turnn OFF debugging, then the UE does attach. But
    the throughput is very, very slow (3-4 seconds between pings) suggesting
    that all I am doing by turning the debugging off is masking the problem....
    
    David
    
    Security Mode Issue with 18.3
    https://sourceforge.net/p/openlte/discussion/general/thread/162b15e6/?limit=25#b5fd/da6b
    
    Sent from sourceforge.net because you indicated interest in
    https://sourceforge.net/p/openlte/discussion/general/
    
    To unsubscribe from further messages, please visit
    https://sourceforge.net/auth/subscriptions/
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Security Mode Issue with 18.3

An open source 3GPP LTE implementation.

Forums

Help

Security Mode Issue with 18.3

David

David

David

David

Security Mode Issue with 18.3

An open source 3GPP LTE implementation.

Forums

Help

Security Mode Issue with 18.3 document.SUBSCRIPTION_OPTIONS = { "thing": "topic", "subscribed": false, "url": "subscribe", "icon": { "css": "fa fa-envelope-o" } };

David

David

David

David

Security Mode Issue with 18.3