Bug #4410

current osmo-remsim-client-st2 fails to open second interface on device

Added by laforge about 1 month ago. Updated about 1 month ago.

Target version:
Start date:
Due date:
% Done:



In recent versions of osmo-remsim-client-st2, we appear to be doing an unconditional USB SET_CONFIGURATION transaction on the control endpoint. This works when opening the first interface of the device, but will fail when opening the second interface:

root@remsim-client:~# osmo-remsim-client-st2 -s -c 23 -n1 -V 1d50 -P 4004 -C0 -I0 -S0 -H 1-
simtrace2-remsim-client - Remote SIM card client for SIMtrace
(C) 2010-2019, Harald Welte <>
(C) 2018, sysmocom -s.f.m.c. GmbH, Author: Kevin Redon <>

<0000> fsm.c:461 RSPRO_CLIENT(server)[0x1790d90]{INIT}: Allocated
<0000> simtrace2-remsim_client.c:1252 RSPRO_CLIENT(server)[0x1790d90]{INIT}: Received Event SRVC_E_ESTABLISH
<0000> ../rspro_client_fsm.c:335 RSPRO_CLIENT(server)[0x1790d90]{INIT}: state_chg to REESTABLISH
<0000> ../rspro_client_fsm.c:290 RSPRO_CLIENT(server)[0x1790d90]{REESTABLISH}: Creating TCP connection to server at
<0000> fsm.c:461 RSPRO_CLIENT(server)[0x1798cd0]{INIT}: Allocated
Cannot set configuration: LIBUSB_ERROR_BUSY
can't open USB device

Thinking of this, this is more or less obvious. As soon as any of the interfaces of a configuration are claimed, one cannot change the configuration anymore. It can probably be argued if setting the same config that already is active is a "change", but well, it is how it is.

The remsim-client and/or libosmocore code needs to be modified to only attempt a SET_CONFIGURATION if the requested config is not already active.

This was observed with remsim-client


#1 Updated by laforge about 1 month ago

kernel log:

[ 7051.529681] usb 1- usbfs: interface 1 claimed by usbfs while 'osmo-remsim-cli' sets config #0

#2 Updated by laforge about 1 month ago

  • % Done changed from 0 to 10
Interestingly, the code in osmo_libusb_open_claim_interface() already does this:
  • get the current configuration
  • only issue a libusbb_set_configuration if the current config differs from the intended config

So either there's a bug in this libosmocore code, or the firmware is returning the wrong value during GET_CONFIGURATION, making the code believe it's not the one we want.

#3 Updated by laforge about 1 month ago

  • Status changed from New to In Progress

couldn't reproduce this with ST34 on the same board. I could use both interfaces in parallel without any trouble. Weird.

#4 Updated by laforge about 1 month ago

  • Status changed from In Progress to Rejected
  • Priority changed from Normal to Low
  • % Done changed from 10 to 60

Cannot reproduce this anymore even on ST12 with current libosmocore / host tools.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)