Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
spice-gtk sends incorrect SpiceLinkMess to server when a channel is established. channel_id and connection_id seem to be swapped which results in server having unusable channel list -- all channels have equal id
Version-Release number of selected component (if applicable):
spice-gtk-0.12-4.el7.x86_64
How reproducible:
Always
Steps to Reproduce:
1. Start capturing packets on your machine
2. Connect to a spice server
3. Cancel capture
4. Disect the capture with wireshark with spice-disector
5. look for CHANNELS_LIST packet
6. Search for packets with SESSION_ID
Actual results:
in 5. all channels will be reported as having ID: 0
in 6. all channels will have different SESSION_ID instead of Channel ID, even though they should be logically in the same session.
Expected results:
it should be the other way around
Additional info:
Created attachment 605197[details]
Connection on main channel showing the wrong behaviour
Completely forgot to attach this file.
Its cut from tshark, shows both SESSION_ID and CHANNEL_ID of main channel, and later there is CHANNEL_LIST packet, which display all channels having the same ID, if required I can add other channels from the session as well (the SESSION_ID is unique for each channel)
Comment 4Christophe Fergeau
2013-12-17 17:34:34 UTC
(In reply to Tomas Jamrisko from comment #0)
> Description of problem:
> spice-gtk sends incorrect SpiceLinkMess to server when a channel is
> established. channel_id and connection_id seem to be swapped which results
> in server having unusable channel list -- all channels have equal id
>
> Version-Release number of selected component (if applicable):
> spice-gtk-0.12-4.el7.x86_64
>
> How reproducible:
> Always
>
> Steps to Reproduce:
> 1. Start capturing packets on your machine
> 2. Connect to a spice server
> 3. Cancel capture
> 4. Disect the capture with wireshark with spice-disector
> 5. look for CHANNELS_LIST packet
> 6. Search for packets with SESSION_ID
>
> Actual results:
> in 5. all channels will be reported as having ID: 0
> in 6. all channels will have different SESSION_ID instead of Channel ID,
> even though they should be logically in the same session.
>
I just tried this on a RHEL7 client, and 6) is correct, they have the right Channel ID, and Session ID is constant. I could not see a CHANNELS_LIST message so did not check 5).
I'm closing this as CLOSED CURRENTRELEASE, but reopen if you can still reproduce this bug.