USB_ModeSwitch

Not quite. What you see there is the answer to the GET_DESCRIPTOR_FROM_DEVICE query, coming back from the device. It's not data going from the host/driver to the device.
This seems to be part of the normal device initialization process. We can always come back there, but there are more things to try first.

The error when setting the configuration means that the command did not arrive at the device. I'll change the code to reopen a command connection after switching. Give me ten minutes ...

Oh, and I edited your previous posts after copying the logs to files. Less scrolling required that way.
Since I have saved the relevant information, you don't need to give me more udev logs for now.

O.K.
Please load the source file at the usual place and test.

If it works (of if it doesn't ...) do one more try with the "sleep(1)" command commented out or removed.

Damned, this took more than ten minutes!

No, still the same behaviour (with or w/o the sleep command)

Looking for default devices
Found default devices (1)
Prepare switching, accessing latest device
OK, Sony control message successfully sent.
Looking for default devices
Found default devices (1)
Setting configuration to 2
Setting configuration to 2 returned: -16
-> See /proc/bus/usb/devices (or call lsusb) for changes. Bye

OK.

Next step: doing exactly what the Windows driver does, and that is to query the device in a certain order and then set the configuration.

Tomorrow.

New round, new luck. Never give in.

Now the special code does exactly what's in the logs up to the point where the configuration is selected. This configuration setting should at least NOT produce an error.

If the return values of the query commands are >=0 then they succeeded. If not, please note the number.

The code is at the usual place.

Don't know if this can help in any way, but I have exactly the some output if I send the command with the device already initialized from windows (and stable in configuration 2).

Please try and add the parameter "-R" to your command line. Just to make sure that a Reset does not help ...

New code is in the making. Some more minutes.

More suspicious commands from the log implemented. Give it a shot. At the known place.

Still no go.

Found default devices (1)
Prepare switching, accessing latest device
OK, Sony control message successfully sent.
Query device, step 1
Querying device returned: 18
Query device, step 2
Querying device returned: 9
Query device, step 3
Querying device returned: 356
Setting configuration to 2
Setting configuration to 2 returned: -16
-> See /proc/bus/usb/devices (or call lsusb) for changes. Bye

The restet option doesen't helps, with both the last an the previous versions of the program, andh the device doesen't switch to modem mode at all.

The output of the command with the -R option is the following

Looking for default devices
Found default devices (1)
Prepare switching, accessing latest device
OK, Sony control message successfully sent.
Query device, step 1
Querying device returned: 18
Query device, step 2
Querying device returned: 9
Query device, step 3
Querying device returned: 356
Setting configuration to 2
Setting configuration to 2 returned: -16
Resetting usb device .....................................................................................................
Reset failed. Can be ignored if device switched OK.
-> See /proc/bus/usb/devices (or call lsusb) for changes. Bye

I see, reset does not help.

Did you test the very last one yet, with the "Class interface" commands?

Command when in storage mode

Found default devices (1)
OK, found default device not in target class mode
Prepare switching, accessing latest device
OK, Sony control message successfully sent.
Query device, step 1
Querying device returned: 18
Query device, step 2
Querying device returned: 9
Query device, step 3
Querying device returned: 356
Setting configuration to 2
Setting configuration to 2 returned: -16
-> See /proc/bus/usb/devices (or call lsusb) for changes. Bye

Command when in modem mode

Looking for default devices
Found default devices (1)
All devices in target class mode
No default device found. Is it connected? Bye

No, that is not the latest version.

Load it again like before. It should give results with "Class interface".

No, that is not the latest version.

Sorry, don't know what went wrong when I compiled the latest source.

I recompiled it and this is the result (same result with or w/o the -C parameter):

Found default devices (1)
Prepare switching, accessing latest device
OK, Sony control message successfully sent.
Class interface, step 1
Class interface returned: -32
Class interface, step 2
Class interface returned: -32
Class interface, step 3
Class interface returned: -32
-> See /proc/bus/usb/devices (or call lsusb) for changes. Bye

P.S. can you add a sort of version number to print in the output messages.

I think can be useful for debugging purposes,and to avoid confusion/misunderstandings, not only in this specific case.

Yes, I will add a kind of version number to the output. Never thought it would take so many edits ...

We might get further if we were able to sniff the USB traffic in LINUX as well. Something seems to be different to the Windows behaviour. I'm looking around for a decent Linux sniffer.

Also, I realized the big delay in the udevmon logs from the removal of the storage device to the adding of the modem device. Thats 18 seconds! Can that be right?