Project

General

Profile

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.

Status:
Rejected
Priority:
Low
Assignee:
-
Category:
remsim-client
Target version:
-
Start date:
02/20/2020
Due date:
% Done:

60%


Description

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 192.168.11.10 -c 23 -n1 -V 1d50 -P 4004 -C0 -I0 -S0 -H 1-1.1.2.1
simtrace2-remsim-client - Remote SIM card client for SIMtrace
(C) 2010-2019, Harald Welte <laforge@gnumonks.org>
(C) 2018, sysmocom -s.f.m.c. GmbH, Author: Kevin Redon <kredon@sysmocom.de>

<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 192.168.11.10:9998
<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 0.2.2.46.3598

History

#1 Updated by laforge about 1 month ago

kernel log:

[ 7051.529681] usb 1-1.1.2.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)