The rfc documentation for MDNS covers one-shot Multicast DNS Queries, as shown below：
The above image contains the phrase: the timeout would also be shortened to two or three seconds.
When I use a python program (using the request.post method) to access http://sdss-server.local:8080/digu via the mdns protocol, I use wireshark to capture the packets as follows:
As shown above, it took 2 seconds for mdns to resolve the domain name, my question is what method can I use to get the time for mdns to resolve the domain name down to within 1 second, like 50ms or 100ms, is there a way to do that?
Related
I am trying to implement a monitoring system using ONOS. I am able to collect the port delta statistics from them using port_stat_changed listener.
In the flow statistics, I get the flow entry, which has selection criterion. This criterion only has only Ethernet information. Is there any way to identify the Source and Destination IP address and Port using ONOS. Any suggestion would be very helpful.
The source and destination IP and MAC if they are not in the Switch's rules can be accessed by the application by taking this information from the packets. If your application does not have access to the packages, I do not think the Switches store this kind of information. In case, then, you're going to have to develop a solution by putting a rule in the Switch to pick up that data.
I am working with pcap in an OS X application to understand packet analysis.
I am working with a app https://github.com/jpiccari/MacAlyzer
but I am getting only raw data but I want to differentiate every domain request into separate and clear way to read request and response value. Please guide me the way to how to develop an application with pcap.
I have tried some code but they translate data into hex format. How do I convert that data into meaningful request and response objects like Charles and Fiddler show?
MacAlyzer wasn't developed for your needs. I know because I'm the author. As already stated, Charles and Fiddler are web proxies and work entirely different (and serve different purposes).
Diving a bit deeper into your question, communication between client and server happens IP-to-IP and not domain-to-domain. Domain information is not contained in the packets at the either the IP or TCP level. Instead computers request domain-to-IP lookup information which is then stored and communication is carried out using the client and server IP addresses.
MacAlyzer, and really libpcap, don't have sophisticated packet dissection (like say Wireshark) and cannot display packet information as verbosely as other programs. Before I lost interest in the project I was planning a library that would allow much richer packet dissection and analysis, but free time became very limited.
As for adding domain information to MacAlyzer, I'll explain at a high-level since it seems you know what you're doing. To include domain information instead of IP address in the Source and Destination columns you could edit function ip_host_string() in ip.m. This function controls how the client and server addresses are displayed. Modifying it to lookup the hostname from IP address and returning the resulting string would cause the domains to be displayed instead of IP addresses.
If you come up with some nice updates, consider submitting a pull request.
Here is the food for thoughts:
http://www.binarytides.com/packet-sniffer-code-c-linux/
Anyway, you will need to use C. Therefore, check the codes of the includes, for example:
http://www.eg.bucknell.edu/~cs363/2014-spring/code/tcp.h
Here is the documentation of "pcap":
http://www-01.ibm.com/support/knowledgecenter/#!/ssw_aix_71/com.ibm.aix.basetrf1/pcap_close.htm
I have a weird problem. I have a successfully working C++ (boost asio) P2P application which works on most of the NAT. The problem is when I give the initial start port number as 1000 it checks if 1000 is free else increment by one and chooses a port and starts handshaking. But when I have 10000, 20000, or any other huge port number the hole punching doesn't work on port restricted cone NAT.
How is that possible? I am pretty sure it nothing to do with the code. and recently it doesn't work on one of my friends' full cone NAT as well, but it has worked in many other full cone NATs. What could be the reason? Is there something I am missing about how a NAT behaves?
In many NAT implementations, there are protection rules in place which prevent one host from tying up a large percentage of ports on the WAN interface, e.g. like described here.
Depending on the router, the NAT table entries have different lifetimes, and there are always limits on how many ports can be allocated to a single client (I've seen numbers from 128 to 4096).
So I think when you get to the point where you need to use high ports, the NAT table for your source IP address is already full (or almost full) with entries from old connections, or connections from other apps, so the router either decides to decline or can't fit the new NAT entry for your port.
However, to be sure, I would try to repeat that on a controlled environment collecting Wireshark dumps on both sides of the NAT and analyze the packets. If possible, it would also be helpful to enable router logs and peek into them.
I understand this is not a "magic bullet", but hope it somehow helps you.
Don't try to choose the port number yourself. The operating system can do this faster and better than your code can.
Bind your socket to port 0 and let the OS choose an available port number for you. You didn't specify what programming language, but it usually involves a call to getsockname() after the bind() call is made to discover what local port is going to be used. Java and .NET have equivalent APIs for doing the same thing.
Then follow all the other steps here:
https://stackoverflow.com/a/8524609/104458
Not sure if this'll help but have you tried having one instance of the client application starting at 1001 and the other starting at 1000, then both increment by 1.
While the 1000 will fail on client B, client A has already tried 1001 and so punched that hole, so hopefully it'll work, right? In theory, it sounds OK in my head.
I am trying to get a list of all IP's on a LAN network. The reason for this is I am writing an application that uses the STAR TSP100LAN receipt printer.
The process for obtaining the IP address of the printer is quite cumbersome for the end user. It involves turning the printer off, holding the paper feed button, turning the printer back on, waiting 15 seconds for the printer to obtain an IP address through DHCP and then finally spitting out a receipt with this information on it.
Seeing as the printer is not Bonjour enabled is it possible to get the IP address through other methods?
Any help is much appreciated! I hope this isn't a repeat question, but through my searching I can't seem to find a solution!
UPDATE: Ok after a bit of thinking I have come up with a pseudo-solution:
Determine the iPad's current IPAddress through NSHost.
Strip the last quadrant from the IPAddress
Using the stripped string as a prefix, iterate 1-255 for the last quadrant
Each iteration, attempt to open a port to the given address using the printer's sdk
If I get a valid response, I know that the IP is a printer
If not I exclude the IP from the available printers list.
So far this has been working, I set a timeout of 5 milleseconds for each port open attempt. But have found that this can return some null results despite there actually being a printer on the network with an IP Address assigned.
Perhaps if I get a null result the first time I should increase the timeout to 15 milleseconds for a second attempt at searching.
Your approach of polling the local /8 subnet is probably the best you can do. I can't find any API to get more detailed information about the network interface (i.e. subnet mask) in iOS. (Although using the subnet mask would be a more correct way to determine the range to iterate, if you could get it.)
As you've seen, 5ms is a pretty tight interval; In my experience, 15ms can STILL be pretty tight for a TCP connection over WiFi. As a next step, I would suggest parallelizing the polling of the range, and thereby enabling you to extend the interval you're willing to wait. The simplest way would probably be to use GCD. You could also start this polling process in the background before the user explicitly needs the printer, which might improve the user-perceived responsiveness of your app.
Alternately, you could use the CFSocket API to open all these connections (CFSocketCreate, CFSocketConnectToAddress, and friends) and get parallelism by servicing them all on the main thread with callbacks/the runloop. Then, as those callbacks come in, make a note of which addresses answer on the given port. Unless the printer isn't using TCP for some reason, this should be workable. Once you know which addresses answer on that port at all, you can iterate over that (hopefully much smaller) list connecting with the printer SDK itself. This approach will give you even more (and way more elegant) parallelism than spawning a huge number of GCD threads, but can be difficult to get your head around if you've not worked with runloops before.
Hope that helps.
You can quickly winnow the list down from 255 to a smaller number by pinging the broadcast address then looking into your arp cache.
Only works for hosts that respond to broadcast pings.
If I understand the parallel port right, sending data from (D0 to D7) simultaneous, but that it can control the sticks individually?
example:
D0 = Input
D1 = Input
D2 = Output
...
...
...
D7 = Input
would it work?
what I want to do is to both send and receive data simultaneously.
Data wires (D0-D7) are being read or set simultaneously. For various tecniques for bidirectional I/O read the attached articles:
Standard parallel port: http://www.beyondlogic.org/spp/parallel.htm
EPP: http://www.beyondlogic.org/epp/epp.htm
ECP: http://www.beyondlogic.org/ecp/ecp.htm
This site is a good source for programming the parallel port.
The basic idea is that you need a DLL, add-on or library that allows you to access the I/O Ports of the PC. For Windows XP on up you need a specific driver that will allow you do this as the OS doesn't offer access out of the box.
The Parallel port will generally reside at one of three address 278,378, 3BC. This port. have the bytes you are reading or writing.
The (base)+1 port allows access to the status bytes. IE. 279,379, 3BD
The (base)+2 port allows access to the control bytes. IE. 27A,37A,3BE
The parallel port documentation will tell not only how to implement the common modes (like bi-directional) but how to control the port at the byte level to implement your own custom.
Back in the day there was only the standard mode available. You pump out your bytes at the (base) port. Some application, like mine, manipulated individual bits of that ports as form of cheap Digital I/O Controller. We did use the status and control bytes as additional inputs and outputs. There were commands you can send to the Parallel Port chip configure the modes precisely.
Today there are are hundreds of sites with example of using the Parallel Port to solve all kinds of problems. I would be surprised that one of doesn't have something you can use for you specific application.
Again the book I recommend starting with is Parallel Port complete. It tells just about everything you need to start with. If your application is too esoteric for that book it will give a springboard from which you can find the exact setup you need.
Of course by sending a number that has just the required bit set (2n) you'd get the expected result.
I'm not sure about bidirectional access though. I guess it's achieved by using control pins along with the data pins but that's just a guess.
Parallel ports doing EPP or ECP only allow D0-D7 to be all input or all output. Trying to do otherwise may fry your hardware.
See http://www.nor-tech.com/solutions/dox/ieee1284_parallel_ports.pdf, page 6.
However, parallel ports have several control lines that may be useful if you only need a small amount of input/output in the "other" direction.
I believe its bit 5 in the port's control register (base address + 2) that switches direction. (no hardware line attached)