I am trying to let two or more ESP32-S2s communicate from one to the others over udp. Since they possibly dont know each others ip i wanted to use multicast.
Sending MulticastPackets is working.(At least I can wireshark the Packets on my PC).
Recieving on the other esp doesnt work so far.
Im Broadcasting to 192.168.178.255:7777
The reciever uses the following code:
//Called once after Wifi is connected:
udp.beginMulticast(OAL_Broadcast, OALPort); // 192.168.178.255, 7777 as inputs
//Called periodically :
Serial.println(udp.parsePacket()); // In my case always returns 0
What am I missing?
A few things could be happening.
The multicast IP address range is between 224.0.0.0-239.255.255.255 and usually a device joins a multicast group on one of those. Also it might treat sending a multicast more loosely when it comes to the IP address but receiving one it must be within the range of multicast addresses due to how it routes that packet to a multicast group.
If one device is on another network device but still on the same network then it could be ttl related and each network device is treated as a hop. I have seen something like this happen before. You might be able to adjust that on the network device side or on the esp32 side.
i have this Wireshark snapshot and im trying to filter for the mdns protocol by just typing: mdns
but it's not working. however filtering for http is working fine.
whats am i doing wrong?
Thanks
![wireshark error] https://www.dropbox.com/s/4zt6nf3f66te5ka/wireshar_pic.PNG?dl=0
Although the Protocol column shows "MDNS", the actual Protocol "field" for display filters to match is "dns", as far as Wireshark is concerned. So using a display filter of "dns" will match DNS packets, including MDNS. To then narrow it down to only MDNS, add the UDP port number of 5353, so the final display filter would be:
dns and udp.port == 5353
...or just "udp.port == 5353" since that's going to be MDNS normally.
mDNS packets are multicast (in opposite to unicast or broadcast) so you should filter them with one of the following filters:
ip == multicast
ip == broadcast
I know you already have the capture file but for future reference - you can filter only multicast traffic using capture filter multicast
EDIT: It doesn't exist see the following link; he offers a solution, similar to my first crack below: Filtering mDNS in WS. He proposes: dns and udp.port eq 5353
This being said, reference the wikipedia page: MDNS
You will see that it publishes to:
IPv4 address 224.0.0.251 or IPv6 address FF02::FB
UDP Port 5353
I would recommend using ip.dst==224.0.0.251 and, if that isn't enough, and that filter with one on the UDP port.
This probably has a very obvious answer, but what is the common way to get the router/gateway IP address of the packet I just received in pcap.net?
I know how to get the IP address source:
packet.Ethernet.IpV4.Source.ToString()
I tried looking through the object browser, but I didn't find a property that seemed to match. Any way I could find it?
It's more of networking question, than programming one. A short answer would be - You can't.
The source IP address will always (unless strangely translated by the gateway) belong to the endpoint You wanted to connect with. This way Your application will get the response to any request You send. Unless You're using NAT the router does not alter the packet in any way so it's transparent from a connectivity point of view. The source address of the packet You just got would almost always contain the IP address of the server You connected to. That's the way Ethernet works.
A poor man's solution would be to use traceroute to find out which way the packets go and therefore get the address of the router, which generally would be the first hop along the way. From a programmer's perspective this would mean sending out several packets to the destination You got the packet from, each time incrementing the packet's TTL (starting from 1) and looking at the ICMP responses. This however could mislead You if some sort of load balancing is being done.
Maybe if You clarified what You would like to achieve I could point You in a better direction.
I am working on an app that monitors network usage. However I noticed many ways to do this does not allow exclusion of local traffic (say, Time Machine).
I am looking for a way to exclude local traffic, and only monitors usage that goes directly to/from the internet.
Update: Thank you for your replies, now I know how to find if the traffic is local, but I still don't know how I can calculate total in/out bytes (sorry if I didn't elaborate earlier). I have no way of knowing how many bytes are sent/received locally (or to the internet) in a certain period of time, or since the OS starts. This problem is further complicated by the fact processes are launched or killed when the OS is running.
The answer to the question How to get network adapter stats in linux/Mac OSX? gives an interesting way of summing up total usage but it doesn't help because the usage it sums up are interface statistics.
Update 2: I've posted my final solution to this. Please scroll down a bit to see.
you need to read the source for ifconfig(8), which describes how to get the status of every attached network interface.
pay particular attention to in_status(), which gets the inet address and netmask of an interface.
when the source or destination address in the traffic has the same host as a local interface
int is_local =
(src && netmask) == (ifaddr && netmask)
|| (dst && netmask) == (ifaddr && netmask)
then you can be sure that it is local
http://www.opensource.apple.com/source/network_cmds/network_cmds-307/ifconfig.tproj/ifconfig.c
Answering you comment about which interfaces carry local traffic is actually complicated, because it depends on what you mean by local traffic.
What “Local” Means
The easiest meaning of "local traffic" is traffic that does not leave the machine its generated on (two programs on the same machine talking to each other, for example). This traffic all goes over lo. This is one thing that people mean when they say local (and what I was thinking of when I answered).
The next easiest meaning would be "IP traffic destined to machines on the same subnet". That'd be traffic that has a destination address inside the local subnet. The easiest way to count this is going to be either the routing table (if Mac OS X counts traffic stats per route, the routes on the various gateways will give you non-local traffic) or with a firewall rule. This probably isn't want anyone means when they say "local traffic".
Another meaning would be "IP traffic destined to machines in this (physical) location". E.g., at my office we have several subnets in use, with routers between them, but traffic from one subnet to the other is still clearly local. You need network knowledge to distinguish local from non-local traffic with this definition.
Another meaning would be "IP traffic destined to machines in my organization". This is a reasonable meaning depending on how your network is set up (e.g., maybe you have fast fiber between your locations, but your Internet connections are much slower, or charged per-GB). Requires in-depth knowledge of the network to figure if a destination is going to be local or not—and, with things like VPNs, that may vary over time.
Finally, "Internet traffic" isn't the opposite of any of those. Sometimes, for example, what appears to be a local machine on your Ethernet segment is actually over a VPN, over the Internet (this isn't crazy, it's very useful for when remote users need to use various Windows services). Traffic inside your organization can easily travel over an Internet VPN.
Cheating in Simple Networks
If the network is very simple, with there being only one internal subnet, only one router, and all traffic not to that internal subnet being Internet traffic, you can cheat and solve this. This probably applies to the vast majority of home networks, and many small business ones as well.
Using firewall rules
In a simple network setup, you can probably make some assumptions, and get a close enough answer by counting traffic as non-local if:
the destination MAC address is the default gateway's MAC address; and
the destination IP address is not the default gateway's IP address
alternatively:
the destination IP address is not within the subnet of the network interface the default route goes out
You can probably create a firewall rule to count either of those. At least with Linux iptables you can, and I'm pretty sure BSD pf, and probably Mac OS X.
Alternate Approach: SNMP
Finally, if you can't use a firewall rule (as that'd require root), you could hope that the default gateway responds to SNMP community public, explore all its interfaces, and find the one with a off-subnet IP address, and then assume that is the Internet link. Then you can ask the router for traffic counts on that interface.
Of course, you'll find that many SOHO routers don't support SNMP, and those that do probably don't have it turned on.
The best way is to find the 'external' ip address through the eth0, eth1, or whatever adapter with a system call to ifconfig. Then pull logs for whatever system (messages, syslog, whatever) and write a filter for that external ip address. To make it nicer and more portable, write a regex that will filter for publicly routable IPs only and just filter messages log for that 'external' ip address.
I think, an approximate solution: getifaddrs can be used to get statistics on network usage.
It can get separate statistics for Wi-Fi and WWAN interfaces.
You might find more information from :
http://www.gsp.com/cgi-bin/man.cgi?section=3&topic=getifaddrs
It depends on how you define "local", but a common definition would be to look at the network mask.
For example, if your IP (ie the IP of the interface you monitor is
10.33.52.123
netmask 255.255.255.0
that would mean every IP-packet with both source-IP and destination-IP 10.33.52.xx is local.
I don't know cocoa or objective-c, but you can probably use some of these functions helping you extract the network from an IP-address: http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/inet_network.3.html
Don't know how to implement it in objective-c but the idea is that you get the address of the network you are in (you can figure this out from network class(A,B,C) based from your local ip or from bits in netmask if it's not standard), then just check the outgoing connection's address. If the destination is not in your local network, calculate traffic; if it's in, just do nothing.
There are three ranges of non-routable IP addresses, and they are commonly used as the address ranges for NAT services. Any address that is not in one of the non-routable address ranges is an external address.
Of course if you are not behind a NAT router, the task is harder (and technically all the addresses short of 127.0.0.1 are external at this point).
The non-routable IP ranges are:
10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255
The final working solution I have is to use libpcap to achieve this. Of course there are some downsides, which includes it requires elevated privileges and must capture all filtered packets to calculate statistics, but at least it works perfectly well.
Many documentations and tutorials on libpcap is fairly thorough and clear, I suggest every one interested in this solution to look at those with relatively little google-fu effort.
Also it may interest a few that my filter for internet traffic is simply the following -
- (NSString *)_internetFilterStringForInterface:(AKNetworkInterface *)interface
inOrOut:(BOOL)inYesOutNo
{
if (![interface net] || ![interface mask] || IsEmpty([interface addresses]))
{
return nil;
}
NSString *hostType = inYesOutNo ? #"dst" : #"src";
NSString *host = nil;
for (NSString *hostComponent in [interface addresses])
{
if (IsEmpty(hostComponent)) continue;
if (!host)
host = [NSString stringWithFormat:#"(%# host %#", hostType, hostComponent];
else
host = [host stringByAppendingFormat:#" or %# host %#", hostType, hostComponent];
}
host = [host stringByAppendingString:#")"];
NSString *net = [interface netString];
net = [net stringByReplacingOccurrencesOfString:#".0" withString:#""];
NSString *filter = [NSString stringWithFormat:
#"ip and (not %# net %#) and %#",
inYesOutNo ? #"src" : #"dst",
net, host];
return filter;
}
The filter is designed with some of the answers about what counts as 'local traffic', I know it does not encompass some edge cases such as double NAT configurations, etc., but I would like to see suggestions about this.
I know net = [net stringByReplacingOccurrencesOfString:#".0" withString:#""]; is just a quick hack which could easily fail under some peculiar circumstances but hey no one is complaining, at least not yet.
I'm attempting to send multichannel audio over WiFi from one server to multiple client computers using UDP broadcast on a private network.
I'm using software called Pure Data, with a UDP broadcast tool called netsend~ and netreceive~. The code is here:
http://www.remu.fr/sound-delta/netsend~/
To cut a long story short, I'm able to achieve sending 9 channels to one client computer in a point-to-point network, but when I try to do broadcast to 2 clients (haven't yet tried more), I get no sound. I can compress the audio and send 4 channels compressed (about 10% size of uncompressed) over UDP broadcast to 2 clients successfully. Or I can send 1 channel over UDP broadcast to 2 clients, with some glitches.
The WiFi router is a Linksys WRT300N. All computers are running Windows XP. The IP addresses are 192.168.1.x, with subnet mask 255.255.255.0 and the subnet broadcast address: 192.168.1.255.
I'm curious - what happens to UDP broadcast packets in the router?
If I have a subnet mask of 255.255.255.0, then does the router make 254 packets for every packet sent ot the broadcast address?
My WiFi bandwidth is at least 100Mbps, but I can't seem to send audio of more than around 10Mbps over UDP broadcast to multiple clients.
What's stopping me from sending audio up to the bandwidth limit of the WiFi?
any suggestions for socket code modifications, network setups, router setups, subnet modifications... all very much appreciated!
thanks
Nick
Your problem is caused by the access point's rate control algorithm. With unicast the access point tracks what data rate every particular receiver can reliably receive at, and sends about that rate. With multicast the access point does not know which receivers are interested in the data, so simple access points send the data at the slowest possible rate (1Mb/s). Better implemented access points may send the data at the rate that the slowest connected client is using, and the best access points use IGMP snooping to see who's receiving each IP multicast stream, and they will choose the slowest rate out of the receivers for that stream.
The simplest solution is to not use multicast when you have a small number of WiFi receivers.
Are all parties connected via WiFi or is the sender using a
wired connection to the Access Point? Broadcast data will
be transmitted as unicast data from a station to an access
point and the access point will then retransmit the data
as broadcast/multicast traffic so it will use twice the
on-air bandwidth compared to when the sender sits on the
wired side of the AP.
When sending a unicast frame the AP will wait for an ACK
from the receiving station and it will retransmit the
frame until the ACK arrives (or it times out). Broadcast/multicast
frames are not ACKed and therefore not retransmitted.
If you have a busy/noisy radio environment this will
cause the likelyhood of dropped packets to increase,
potentially a lot, for multicast traffic compared to unicast
traffic. In an audio application this could certainly be audible.
Also, IIRC, broadcast/multicast traffic does not use the
RTS/CTS procedure for reserving the media which exarbates
the dropped packets problem.
It could actually be the case that multiple unicast streams
work better than a single multicast stream under less-than-ideal
radio conditions given that the aggregated bandwidth is
high enough.
If you can I would suggest that you use wireshark to sniff
the WiFi traffic and take a look at the destination address
in the 802.11 header. Then you can verify if the packets
are actually broadcast or not over the air.
Your design is failing due to a common misconception with WiFi speeds. With 802.11n the number 300mb/s is the link speed, not the actual bandwidth available for user data or even the IP layer. The effective bandwidth is closer to 40mb/s best case, have a look at the FAQ on SmallNetBuilder.com that discusses this in further detail.
http://www.smallnetbuilder.com/wireless/wireless-basics/31083-smallnetbuilders-wireless-faq-the-essentials
I'm curious - what happens to UDP broadcast packets in the router? If I have a subnet mask of 255.255.255.0, then does the router make 254 packets for every packet sent ot the broadcast address?
No the "router" doesn't make 254 individual packets. Furthermore, I suspect the protocol leverages "multicast" addresses rather than using a "broadcast" address.
Since broadcast/multicast traffic can easily be misused, there are many networking equipment that limit/block by default such traffic. Of course, some essential protocols (e.g. ARP, DHCP) rely on broadcast/multicast addresses to function and won't be blocked by default.
Hence, it might be a good thing to check for multicast/broadcast control knobs on your router.