Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to diagnose an issue? Unix receiver idles on "Starting ... " #100

Open
afparsons opened this issue Jun 27, 2020 · 18 comments
Open

How to diagnose an issue? Unix receiver idles on "Starting ... " #100

afparsons opened this issue Jun 27, 2020 · 18 comments

Comments

@afparsons
Copy link
Contributor

afparsons commented Jun 27, 2020

I'm excited to try and use scream to send audio from a Windows 10 laptop to a Linux server (and then over 3.5mm aux into an audio receiver).

I believe I've gotten scream installed on the Windows laptop correctly. (see #98 )
I also believe that I've correctly compiled the unix receiver on my Linux server (Proxmox).

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 10 (buster)
Release:	10
Codename:	buster

Using speaker-test, I've confirmed that I have audio correctly working.

I can:

  • launch YouTube on the Windows machine and set the output device to Scream
  • run the scream receiver with various flags

The scream receiver doesn't seem to be receiving any audio. I'm not sure how to further diagnose the issue.

My Linux server is a laptop networked via ethernet on eno1.

$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr0 state UP mode DEFAULT group default qlen 1000
    link/ether 10:1f:74:69:a2:88 brd ff:ff:ff:ff:ff:ff
3: enx64d4da6b44df: <NOARP> mtu 1400 qdisc noop state DOWN mode DEFAULT group default qlen 20
    link/ether 64:d4:da:6b:44:df brd ff:ff:ff:ff:ff:ff
4: wlo1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
    link/ether 40:25:c2:b4:8a:b8 brd ff:ff:ff:ff:ff:ff
5: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 10:1f:74:69:a2:88 brd ff:ff:ff:ff:ff:ff
6: tap100i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr0 state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether 52:7c:1b:aa:cc:22 brd ff:ff:ff:ff:ff:ff

Running with -o alsa (pulseaudio is the same):

scream/Receivers/unix/build$ ./scream -i eno1 -v -o alsa
Using ALSA output
Starting multicast receiver

What should I try next?


Edit: I should add that even though I am using Proxmox, I am running the scream receiver on the host, not in a VM.

@duncanthrax
Copy link
Owner

Do a tcpdump like tcpdump -pni eno1 port 4010 to see if you get any packets while playing sound. If you don't get any, try unicast (see the README.md on the github frontpage).

@afparsons
Copy link
Contributor Author

afparsons commented Jun 27, 2020

I was just about to comment with some tcpdump output! You beat me to it. Thanks for the quick response @duncanthrax .

$ sudo tcpdump -pni eno1 port 4010 -c5
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eno1, link-type EN10MB (Ethernet), capture size 262144 bytes
16:41:10.195685 IP 10.0.0.57.4010 > 239.255.77.77.4010: UDP, length 1157
16:41:10.196422 IP 10.0.0.57.4010 > 239.255.77.77.4010: UDP, length 1157
16:41:10.205085 IP 10.0.0.57.4010 > 239.255.77.77.4010: UDP, length 1157
16:41:10.214919 IP 10.0.0.57.4010 > 239.255.77.77.4010: UDP, length 1157
16:41:10.215588 IP 10.0.0.57.4010 > 239.255.77.77.4010: UDP, length 1157
5 packets captured
5 packets received by filter
0 packets dropped by kernel

I'm definitely receiving the packets.

Based on the readme...I guess I should use the -P libpcap flag?

$ sudo apt-get install libpcap0.8 libpcap0.8-dev libpcap-dev
Reading package lists... Done
Building dependency tree       
Reading state information... Done
libpcap-dev is already the newest version (1.8.1-6).
libpcap0.8 is already the newest version (1.8.1-6).
libpcap0.8-dev is already the newest version (1.8.1-6).
0 upgraded, 0 newly installed, 0 to remove and 21 not upgraded.

So I would assume I should compile with libpcap available:

$ cmake ..
-- Checking for module 'libpcap'
--   No package 'libpcap' found
-- Configuring done
-- Generating done
-- Build files have been written to: /home...<blah blah blah>.../build

Here is the output from various permutations of dpkg -L libpcap*:

$ dpkg -L libpcap-dev
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/libpcap-dev
/usr/share/doc/libpcap-dev/changelog.Debian.gz
/usr/share/doc/libpcap-dev/changelog.gz
/usr/share/doc/libpcap-dev/copyright
aparsons@dm4:~$ dpkg -L libpcap0.8
/.
/usr
/usr/lib
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/libpcap.so.1.8.1
/usr/share
/usr/share/doc
/usr/share/doc/libpcap0.8
/usr/share/doc/libpcap0.8/CREDITS.gz
/usr/share/doc/libpcap0.8/README
/usr/share/doc/libpcap0.8/README.Debian
/usr/share/doc/libpcap0.8/changelog.Debian.gz
/usr/share/doc/libpcap0.8/changelog.gz
/usr/share/doc/libpcap0.8/copyright
/usr/share/man
/usr/share/man/man7
/usr/share/man/man7/pcap-filter.7.gz
/usr/lib/x86_64-linux-gnu/libpcap.so.0.8
aparsons@dm4:~$ dpkg -L libpcap0.8-dev
/.
/usr
/usr/bin
/usr/bin/pcap-config
/usr/include
/usr/include/pcap
/usr/include/pcap/bluetooth.h
/usr/include/pcap/bpf.h
/usr/include/pcap/can_socketcan.h
/usr/include/pcap/dlt.h
/usr/include/pcap/export-defs.h
/usr/include/pcap/ipnet.h
/usr/include/pcap/namedb.h
/usr/include/pcap/nflog.h
/usr/include/pcap/pcap.h
/usr/include/pcap/sll.h
/usr/include/pcap/usb.h
/usr/include/pcap/vlan.h
/usr/include/pcap-bpf.h
/usr/include/pcap-namedb.h
/usr/include/pcap.h
/usr/lib
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/libpcap.a
/usr/share
/usr/share/doc
/usr/share/doc/libpcap0.8-dev
/usr/share/doc/libpcap0.8-dev/changelog.Debian.gz
/usr/share/doc/libpcap0.8-dev/changelog.gz
/usr/share/doc/libpcap0.8-dev/copyright
/usr/share/man
/usr/share/man/man1
/usr/share/man/man1/pcap-config.1.gz
/usr/share/man/man3
/usr/share/man/man3/pcap.3pcap.gz
/usr/share/man/man3/pcap_activate.3pcap.gz
/usr/share/man/man3/pcap_breakloop.3pcap.gz
/usr/share/man/man3/pcap_can_set_rfmon.3pcap.gz
/usr/share/man/man3/pcap_close.3pcap.gz
/usr/share/man/man3/pcap_compile.3pcap.gz
/usr/share/man/man3/pcap_create.3pcap.gz
/usr/share/man/man3/pcap_datalink.3pcap.gz
/usr/share/man/man3/pcap_datalink_name_to_val.3pcap.gz
/usr/share/man/man3/pcap_datalink_val_to_name.3pcap.gz
/usr/share/man/man3/pcap_dump.3pcap.gz
/usr/share/man/man3/pcap_dump_close.3pcap.gz
/usr/share/man/man3/pcap_dump_file.3pcap.gz
/usr/share/man/man3/pcap_dump_flush.3pcap.gz
/usr/share/man/man3/pcap_dump_ftell.3pcap.gz
/usr/share/man/man3/pcap_dump_open.3pcap.gz
/usr/share/man/man3/pcap_file.3pcap.gz
/usr/share/man/man3/pcap_fileno.3pcap.gz
/usr/share/man/man3/pcap_findalldevs.3pcap.gz
/usr/share/man/man3/pcap_freecode.3pcap.gz
/usr/share/man/man3/pcap_get_selectable_fd.3pcap.gz
/usr/share/man/man3/pcap_get_tstamp_precision.3pcap.gz
/usr/share/man/man3/pcap_geterr.3pcap.gz
/usr/share/man/man3/pcap_inject.3pcap.gz
/usr/share/man/man3/pcap_is_swapped.3pcap.gz
/usr/share/man/man3/pcap_lib_version.3pcap.gz
/usr/share/man/man3/pcap_list_datalinks.3pcap.gz
/usr/share/man/man3/pcap_list_tstamp_types.3pcap.gz
/usr/share/man/man3/pcap_lookupdev.3pcap.gz
/usr/share/man/man3/pcap_lookupnet.3pcap.gz
/usr/share/man/man3/pcap_loop.3pcap.gz
/usr/share/man/man3/pcap_major_version.3pcap.gz
/usr/share/man/man3/pcap_next_ex.3pcap.gz
/usr/share/man/man3/pcap_offline_filter.3pcap.gz
/usr/share/man/man3/pcap_open_dead.3pcap.gz
/usr/share/man/man3/pcap_open_live.3pcap.gz
/usr/share/man/man3/pcap_open_offline.3pcap.gz
/usr/share/man/man3/pcap_set_buffer_size.3pcap.gz
/usr/share/man/man3/pcap_set_datalink.3pcap.gz
/usr/share/man/man3/pcap_set_immediate_mode.3pcap.gz
/usr/share/man/man3/pcap_set_promisc.3pcap.gz
/usr/share/man/man3/pcap_set_rfmon.3pcap.gz
/usr/share/man/man3/pcap_set_snaplen.3pcap.gz
/usr/share/man/man3/pcap_set_timeout.3pcap.gz
/usr/share/man/man3/pcap_set_tstamp_precision.3pcap.gz
/usr/share/man/man3/pcap_set_tstamp_type.3pcap.gz
/usr/share/man/man3/pcap_setdirection.3pcap.gz
/usr/share/man/man3/pcap_setfilter.3pcap.gz
/usr/share/man/man3/pcap_setnonblock.3pcap.gz
/usr/share/man/man3/pcap_snapshot.3pcap.gz
/usr/share/man/man3/pcap_stats.3pcap.gz
/usr/share/man/man3/pcap_statustostr.3pcap.gz
/usr/share/man/man3/pcap_strerror.3pcap.gz
/usr/share/man/man3/pcap_tstamp_type_name_to_val.3pcap.gz
/usr/share/man/man3/pcap_tstamp_type_val_to_name.3pcap.gz
/usr/share/man/man5
/usr/share/man/man5/pcap-savefile.5.gz
/usr/share/man/man7
/usr/share/man/man7/pcap-linktype.7.gz
/usr/share/man/man7/pcap-tstamp.7.gz
/usr/lib/x86_64-linux-gnu/libpcap.so
/usr/share/man/man3/pcap_datalink_val_to_description.3pcap.gz
/usr/share/man/man3/pcap_dispatch.3pcap.gz
/usr/share/man/man3/pcap_dump_fopen.3pcap.gz
/usr/share/man/man3/pcap_fopen_offline.3pcap.gz
/usr/share/man/man3/pcap_fopen_offline_with_tstamp_precision.3pcap.gz
/usr/share/man/man3/pcap_free_datalinks.3pcap.gz
/usr/share/man/man3/pcap_free_tstamp_types.3pcap.gz
/usr/share/man/man3/pcap_freealldevs.3pcap.gz
/usr/share/man/man3/pcap_getnonblock.3pcap.gz
/usr/share/man/man3/pcap_minor_version.3pcap.gz
/usr/share/man/man3/pcap_next.3pcap.gz
/usr/share/man/man3/pcap_open_dead_with_tstamp_precision.3pcap.gz
/usr/share/man/man3/pcap_open_offline_with_tstamp_precision.3pcap.gz
/usr/share/man/man3/pcap_perror.3pcap.gz
/usr/share/man/man3/pcap_sendpacket.3pcap.gz
/usr/share/man/man3/pcap_tstamp_type_val_to_description.3pcap.gz

@duncanthrax
Copy link
Owner

Hmmm, the cmake recipe uses pkg-config to find libpcap. Probably you have this problem:
https://bugs.launchpad.net/ubuntu/+source/libpcap/+bug/1865501

@martinellimarco
Copy link
Collaborator

@afparsons do you have a firewall enabled?
I don't use Debian but I think you can see it with sudo systemctl status firewall.service
If that fail try sudo systemctl status firewalld.service or sudo ufw status.

@kaisparkle
Copy link

I'm having a similar issue, except I'm attempting to pass audio up through a Windows VM. Similar setup, except using libvirt networking. It's exhibiting the same symptoms as here - packets are clearly received on the host, either through unicast or multicast, but running an strace shows that they aren't reaching the receiver (no activity).

In my case, I have UFW installed, but the same problem was exhibited even after ports 4010 and 4011 were allowed through, or if UFW was disabled entirely. Not sure how to continue diagnosing from here. As a side note, I haven't been able to get IVSHMEM working either, but that's unrelated to this issue.

@martinellimarco
Copy link
Collaborator

@kaisparkle What's your distro? For example on Ubuntu I've seen both UFW and firewalld at the same time and even if one was allowing the port the other one wasn't. I banged my head around it for a few days.

Try sudo systemctl status firewalld.service and see if it's installed / enabled.

If that's not it look at iptables rules and see what's in there.

UFW is a strange beast. On one hand it's easy to use but its not aware of any rule managed by others. I discovered this the hard way when I configured UFW to deny anything from outside, then installed docker and found out I could happily connect from the outside because docker was managing it's own iptables rules.

@kaisparkle
Copy link

@martinellimarco I'm on Arch, so I've only got UFW installed at the moment. I'm pretty unfamiliar with iptables, but I've posted the output of iptables -S here. https://pastebin.com/0jxpe0Bq

@martinellimarco
Copy link
Collaborator

Just for testing run the following commands. They'll flush any iptables rule and set it to accept everything. It's temporary and not saved on disk but it will show us if the problem is firewall or not.

sudo iptables -t nat -F
sudo iptables -t mangle -F
sudo iptables -F
sudo iptables -X
sudo iptables -P INPUT ACCEPT
sudo iptables -P FORWARD ACCEPT
sudo iptables -P OUTPUT ACCEPT

sudo iptables -S

If it doesn't work what kind of virtual interface are you using between host and guest? Also try this

@kaisparkle
Copy link

kaisparkle commented Jul 16, 2020

No dice there, so it's not the firewall. I already had the suggestions in that post enabled - first thing I tried when I was digging through issues for a solution :)

I'm using virt-manager's default configuration, which is the virbr0 bridge, with forward mode="nat".

Here's the XML for the network configuration.

<network>
  <name>default</name>
  <uuid>dd5f00e5-f9fe-4ffe-a52e-3d6fa65b8b64</uuid>
  <forward mode='nat'/>
  <bridge name='virbr0' stp='on' delay='0'/>
  <mac address='52:54:00:0e:4b:b7'/>
  <ip address='192.168.122.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.122.2' end='192.168.122.254'/>
    </dhcp>
  </ip>
</network>

@martinellimarco
Copy link
Collaborator

Have you tested this with anycast or unicast? Try unicast.

Also since your are using a bridge I think it's worth checking sudo ebtables -L which is the ethernet bridge firewall.

@kaisparkle
Copy link

kaisparkle commented Jul 16, 2020

Yeah, tried with default and I'm using unicast right now with these arguments: scream -u -p 4011 -i virbr0 -o pulse

ebtables -L output:

Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 0, policy: ACCEPT

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT

@martinellimarco
Copy link
Collaborator

can you confirm with any other program that a connection is possible between host and guest? Usually I use netcat for that.

nc -l -p 4010 -u on linux
nc.exe IP_OF_THE_LINUX_BOX 4010 -u on windows

Type something, you should see it on the other end.

If you don't have netcat try with python -m SimpleHTTPServer on linux and on windows open a browser and visit http://IP_OF_THE_LINUX_BOX

@kaisparkle
Copy link

kaisparkle commented Jul 16, 2020

I can send a message with netcat from the Windows 10 guest to the host, but I have to restart netcat on both ends after a message, otherwise the next won't be received. Additionally, I can only send to the host, not the other way around.

@martinellimarco
Copy link
Collaborator

martinellimarco commented Jul 16, 2020

ok, at least we confirmed it's a network problem and not a scream one. In about an hour I'll be at home and I'll be able to setup a new VM with the same virtual NIC you posted above. Let's see if I can reproduce the issue.

Can you capture packets with wireshark while you do the netcat test and send me the file?

@martinellimarco
Copy link
Collaborator

Sorry @kaisparkle, I can't reproduce the problem.

I've tested with a fresh windows VM with windows firewall disabled but that shouldn't be the problem as you already confirmed you see the packets on the host. For the network I just copied your xml. I've tested with and without UFW enabled. With it enabled I just had to open the port with ufw allow 4010/udp. Tested both multicast and unicast.

I'd really like to see the wireshark log if you have the time.

@kaisparkle
Copy link

I'm not entirely sure how to run Wireshark on the host - I'm using a single GPU configuration, so X is killed on VM start and the GPU is passed over. I can probably reconfigure it with a virtual GPU for testing, but I've got work today (unfortunately 😛) so it might be a while.

@martinellimarco
Copy link
Collaborator

You can use tcpdump from a terminal.

The command should be tcpdump -s 0 -i virbr0 -w log.pcap

@ZanderFoster
Copy link

Hello, I am currently trying to pass audio from my windows vm running under a Ubuntu 20.04 host.
I seem to have the exact same issue as OP, when I run the above commands used to troubleshoot I get the exact same output.

@martinellimarco if you or anyone else here wants to figure out this issue I'll be the test subject.

P.s I am new to commenting on issues so apologies if I shouldn't comment in a year old issue as I do not know proper etiquette.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants