Bug #4410
closedcurrent osmo-remsim-client-st2 fails to open second interface on device
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
Updated by laforge about 4 years ago
kernel log:
[ 7051.529681] usb 1-1.1.2.1: usbfs: interface 1 claimed by usbfs while 'osmo-remsim-cli' sets config #0
Updated by laforge about 4 years ago
- % Done changed from 0 to 10
- 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.
Updated by laforge about 4 years 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.
Updated by laforge about 4 years 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.