any Windows networking mavens out there?

[mzimmers]

Hi all -

This one has us stumped. The app I've written opens UDP sockets, one for broadcast and one for multicast. It then sends messages on both sockets, every 3 seconds, until it gets a response.

I've distributed the binary to a handful of team members. We've all been using Wireshark to monitor network traffic.

One person sees both broadcasts and multicasts.

One person sees nothing.

Two others (one of whom is me) see multicasts only.

Everyone running Windows 10 Professional.

We've scoured our respective systems. Windows Firewall is turned off, and there's no other security app that we're aware of that could be inhibiting these broadcasts.

When I step through the code in the debugger, both socket sends return success. My app thinks it's sending.

We're all thinking it's got to be some obscure Windows setting that is frogging this up. Anyone here with some background in Windows apps that might have an idea?

Thanks...

[MEMekaniske]

@mzimmers said in any Windows networking mavens out there?:

We've scoured our respective systems. Windows Firewall is turned off, and there's no other security app that we're aware of that could be inhibiting these broadcasts.

Are you guys working on w/LAN or are you working on seperate networks connected by internet?
Both UDP and Multicast needs to be opened in each router if working seperatly.

There is also the need for port forwarding if you are connected by the internet and not any LAN.

Also, are you using a port that you know is free'd up in the windows system or have you just chosen a port?
Might be that the port is already in use on some recipients.

Do you mind sharing your socket sender and receiver setup code?

[mzimmers]

Most of us are working on a LAN; one person is remote. But we're not trying to communicate with each other (yet); right now, the goal is to determine why some systems don't seem to be producing broadcasts.

We're fairly sure the socket ports are available; they're reserved in our company for this purpose.

Here's the code; I chopped some stuff out, but I think there's enough here to show what I'm doing.

    nics = QNetworkInterface::allInterfaces();
    for (nic = nics.begin(); nic != nics.end(); ++nic)
    {
		// exclude certain NICs (omitted for brevity)

        addrs = nic->addressEntries();
        for (addr = addrs.begin(); addr != addrs.end(); ++addr)
        {
            qha = addr->ip();
            if (qha.protocol() == QAbstractSocket::IPv4Protocol) // currently ignoring IP6 addresses.
            {
                sockInfo.nic = *nic;
                sockInfo.addr = *addr;
                m_socks.append(sockInfo);
                break;
            }
        }
    }
	pSockBroadcast = new QUdpSocket;
	sock->sockBroadcast = pSockBroadcast;

	// set some options for the socket.
	qVar = 1;
	pSockBroadcast->setSocketOption(QAbstractSocket::QAbstractSocket::KeepAliveOption, qVar);

	qVar = 0;
	pSockMulticast->setSocketOption(QAbstractSocket::MulticastLoopbackOption, qVar);

	// bind.
	bindFlags = QAbstractSocket::BindFlag::ShareAddress | QAbstractSocket::ReuseAddressHint;
	rc = pSockBroadcast->bind(qha, VOIP_BROADCAST_PORT, bindFlags);
	if (pSockBroadcast->state() != QAbstractSocket::BoundState)
	{
		qDebug() << "broadcast bind failed on" << sock->nic.humanReadableName();
		continue;
	}
	// send.
	msg = QByteArray::fromStdString("<XML><PacketType>Request</PacketType><ProductName>ETC Speaker</ProductName></XML>");
	m_datagramOut.setData(msg);
	m_datagramOut.setDestination(m_addrBroadcast, VOIP_BROADCAST_PORT);
	rc = it->sockBroadcast->writeDatagram(m_datagramOut);

Thanks for looking.

[kshegunov]

Is it possible you may be hitting something like this?

[mzimmers]

@kshegunov interesting thread, but I don't think it applies to my situation. My sockets remain open until explicitly closed (which in fact they never are), and I'm only sending one message at a time.

I really don't think this is a coding problem; out of the 4 people who have tried the app, 2 now (up from 1) are seeing both the multicast and the broadcast. My money is either on some ultra-obscure Windows setting, or some behind-the-scenes blocking done by the LAN hardware.

[kshegunov]

@mzimmers said in any Windows networking mavens out there?:

My sockets remain open until explicitly closed (which in fact they never are), and I'm only sending one message at a time.

I don't follow. UDP has no notion of "opened" or "closed" the socket either is bound, or not and there it stops. There's no requirement (or even a definition) of a connection, so opened or closed don't apply at all. You can write datagrams successfully even if there's no real connection between the devices.

My money is either on some ultra-obscure Windows setting, or some behind-the-scenes blocking done by the LAN hardware.

The latter being exactly the working hypothesis in the sourced thread.

[mzimmers]

@kshegunov said in any Windows networking mavens out there?:

I don't follow. UDP has no notion of "opened" or "closed" the socket either is bound, or not and there it stops. There's no requirement (or even a definition) of a connection, so opened or closed don't apply at all. You can write datagrams successfully even if there's no real connection between the devices.

Bad choice of words on my part. The sockets are created and bound at app start-up, and never destroyed.

My money is either on some ultra-obscure Windows setting, or some behind-the-scenes blocking done by the LAN hardware.

The latter being exactly the working hypothesis in the sourced thread.

I'm not connecting the dots -- where in that thread is there reference to the possibility of jinky LAN hardware?

[kshegunov]

@mzimmers said in any Windows networking mavens out there?:

Bad choice of words on my part. The sockets are created and bound at app start-up, and never destroyed.

Fair enough.

I'm not connecting the dots -- where in that thread is there reference to the possibility of jinky LAN hardware?

Not strictly hardware, but at the end where the suspect is an ARP cache refresh for which the OS's waiting and supposedly discards the pending datagrams instead of flushing them through the network. Now I don't know if that's at all connected to your case, but my point was you could try a simplified case to test if it may be ...

Another thing that comes to mind, do you capture the errors signal?

[mzimmers]

Another thing that comes to mind, do you capture the errors signal?

Yes...no hits. And I check the return value of the send() in the debugger; all looks good. The app definitely thinks it's sending those broadcasts.

Regarding the other thread, if I understand, that poster is (at the end) sending one message, then going into a short delay, then sending a ton of stuff all at once. He's attributing the delay to what's causing his program to work properly.

But in my instance, I'm only sending one message every 3 seconds (or far less frequently when using the debugger), and I never see any output in Wireshark. So I'm still not sure what the takeaway is.

[SGaist]

Hi,

Did you try to inspect your network activity with a tool like wireshark ?

[kshegunov]

@mzimmers said in any Windows networking mavens out there?:

But in my instance, I'm only sending one message every 3 seconds (or far less frequently when using the debugger), and I never see any output in Wireshark. So I'm still not sure what the takeaway is.

Something else you could try is to drop the shared flag and the multicast at least for time being and try an ordinary p2p datagram. Other than that nothing else comes to mind.

[MEMekaniske]

Hey!

You are adding all known addresses to m_socks but I do not see you add it to your packets/sender anywhere?
Also I cannot find any declaration for the addr m_addrBroadcast?

[MEMekaniske]

qha = addr->ip(); only declares one ip? when what you might need to do is iterate over the socket list?

[mzimmers]

@SGaist yes, all of us did. That's the basis for my reported results.

[mzimmers]

@MEMekaniske said in any Windows networking mavens out there?:

Hey!

You are adding all known addresses to m_socks but I do not see you add it to your packets/sender anywhere?

Ladies and gentlemen, we have a winner!

I didn't realize I had to do that. The corrected code is:

for (it = m_socks.begin(); it != m_socks.end(); ++it)
{
	m_datagramOut.setData(msg);
	m_datagramOut.setSender(it->addr.ip());
	m_datagramOut.setDestination(m_addrBroadcast, VOIP_BROADCAST_PORT);
	rc = it->sockBroadcast->writeDatagram(m_datagramOut);

and it works! (at least on my system)

I can't even hazard a guess as to why the app worked without this added line on some systems.

But...thanks a ton, MEMekaniske.

[MEMekaniske]

@mzimmers

Hey, glad it sends out to everyone now :)
As I could not see the m_addrBroadcast declaration anywhere it's hard to say why it was not using the broadcast addr.

Anyways, if this works fine, no need to use more time on it I guess :)

[mzimmers]

@MEMekaniske yes indeed. Here's the assignment you asked about:

    m_addrBroadcast.setAddress(QHostAddress::Broadcast);

This is done in the c'tor of the class.

Thanks again.

[MEMekaniske]

@mzimmers

Hey, following that call I get the wrong broadcast addr for my network.
Cannot seem to get Qt to deliver the broadcast addr at all, it just returns the netmask with the last bits flipped and not the gateway

When calculating the broadcast addr myself then I get the correct one and it works fine.
Maybe you should set up a script yourself to calculate the broadcast addr for the system and let qt do other things :p

[mzimmers]

@MEMekaniske that's strange -- my datagrams are all fine, and according to Wireshark have all the correct addresses. What OS are you running?

[MEMekaniske]

@mzimmers If i iterate over the interfaces like in your script, then it works with no problem :)
Running on windows :)

When using only the QHostAddress::Broadcast I get the wrong broadcast addr. I too think it is strange, but this is no issue for me, as it's always simple to determine the right address by code or manually :) just strange as you say :)

Anways, off to new issues :D