If I use flowlog, I want to trace that packet. Is there some way to follow a packet for example from the source ip to the lb to the webserver? Is there some kind of id for each request?
Related
Consider a simple IPv6 multicast application:
A "talker" program periodically sends out IPv6 UDP packets to a well-known multicast-group, sending them to a well-known port.
Zero or more "listener" programs bind themselves to that well-known port and join the well-known multicast group, and they all receive the UDP packets.
That all works pretty well, except in the case where one or more of the listener-programs is unable to bind to the well-known UDP port because a socket in some other (unrelated) program has already bound to that UDP port (and didn't set the SO_REUSEADDR and/or SO_REUSEPORT options to allow it to be shared with anyone else). AFAICT in that case, the listener program is simply out of luck, there is nothing it can do to receive the multicast data, short of asking the user to terminate the interfering program in order to free up the port.
Or is there? For example, is there some technique or approach that would allow a multicast listener to receive all the incoming multicast packets for a given multicast-group, regardless of which UDP port they are being sent to?
If you want to receive all multicast traffic regardless of port, you'd need to use raw sockets to get the complete IP datagram. You could then directly inspect the IP header, check if it's using UDP, then check the UDP header before reading the application layer data. Note that methods of doing this are OS specific and typically require administrative privileges.
Regarding SO_REUSEADDR and SO_REUSEPORT, apps that do this will allow multiple programs to receive multicast packets sent to a given port. However, if you also need to receive unicast packets this method has issues. Incoming unicast packets may be set to both sockets, may always be sent to one specific socket, or sent to each in an alternating fashion. This also differs based on the OS.
I can capture packets using tcpdump OK as the source eth1 port is connected to a cisco switch span port, and filter using tcpdump options (at this stage interested in DNS packets to and from a particualar IP only). Rather than writing to a file, I want to simply dump the filtered raw (DNS) packets onto eth2 (which could be unnumbered or numbered). The reason for this is that a 3rd party needs access to the raw data, but I need to filter non-DNS traffic (otherwise I'd just let them connect to the switch span port).
Preferably I also want to run the process continuously. Is there an easy way to direct the tcpdump output to an unnumbered eth interface, or is there a better way of achieving this?
i am programming something about upnp and i would like to clear something :)
When i search with multicast M-Search message, devices must respond, with something like this(it is not complete message, i shortened it)
HTTP/1.1 200 OK
CACHE-CONTROL: max-age = seconds until advertisement expires
DATE: when response was generated
EXT:
LOCATION: URL for UPnP description for root device
So, location is some IP and port, from where i can get description. Now, i would like to search for specific device with unicast. My question is: can i use this address when i am trying to search for this device using UNICAST search message? or devices are listening on another address for unicast msearch messages? :) I have read upnp device architecture pdf file
Yes you can and must continue with unicast. LOCATION is not only "some IP and port" but a full resource location of device description. You can't do multicast to a single address :) There is no more "searching for this device" to do. You simply ask for that URL with HTTP GET. And you will basically get some more URLs of the specific services.
If you are "programming something about upnp" and having this kind of fundamental questions, i recommend downloading UPnP specifications bundle and reading document UPnP-arch-DeviceArchitecture. It describes in understandable steps, how the searching and querying phase of UPnP works.
Update upon OP's clarification:
Rediscovery of a device happens as unicast request to the IP known from original response (to multicast SEARCH) and either the standard port 1900 or a specific port, if the device announced itself via NOTIFY multicast message with a SEARCHPORT.UPNP.ORG value. So if the device needs rediscovery and didn't announce itself, the port defaults to 1900. See also the next page 32 in UPnP device architecture, description of HOST header field.
Note however, that such rediscovery should not be necessary, or very rarely. UPnP devices are expected to announce themselves upon connecting to the network with NOTIFY multicast packet of type ssdp:update, and type ssdp:byebye upon disconnecting. Furthermore, most of the devices have evented variables to which control points should subscribe automatically, and renew their subscription by a fixed lease time (by default 30 minutes). So an abrupt disappearance of device will be discovered anyway (by failed subscription renewal).
Suppose a client sends a number of datagrams to a server through my application. If my application on the server side stops working and cannot receive any datagrams, but the client still continues to send more data grams to the server through UDP protocol, where are those datagrams going? Will they stay in the server's OS data buffer (or something?)
I ask this question because I want to know that if a client send 1000 datagrams (1K each) to a PC over the internet, will those 1000 datagrams go through the internet (consuming the bandwidth) even if no one is listening to those data?
If the answer is Yes, how should I stop this happening? I mean if a server stops functioning, how should I use UDP to get to know the fact and stops any further sending?
Thanks
I ask this question because I want to know that if a client send 1000 datagrams (1K each) to a PC over the internet, will those 1000 datagrams go through the internet (consuming the bandwidth) even if no one is listening to those data?
Yes
If the answer is Yes, how should I stop this happening? I mean if a server stops functioning, how should I use UDP to get to know the fact and stops any further sending?
You need a protocol level control loop i.e. you need to implement a protocol to take care of this situation. UDP isn't connection-oriented so it is up to the "application" that uses UDP to account for this failure-mode.
UDP itself do not provide facilities to determine if message is successfully received by a client or not. You need you TCP to establish reliable connection and after it sends data over UDP.
The lowest overhead solution would be a keep-alive type thing like jdupont suggested. You can also change to use tcp, which provides this facility for you.
Can someone point me to some tutorial on how to set up a ping method using C sockets? Using beej's guide, I've been able to set up a connection between two devices, but now I want to setup a method that pings for all available devices before starting an actual connection. I've never done this before, so would you do something like set up a multicast socket to broadcast an empty data packet and then have the receiver of that empty packet fill it with their IP address and return that now full data packet so that you have the address to start the connection? Any guide's/ help would be appreciated!
Most current IP stacks will not respond to a ping request to a broadcast address. The feature was abused for denial of service attacks.
Implementing a real ping implementation won't be easy, I'd suggest you use an existing lib:
http://www.kernelthread.com/projects/hanoi/html/icmp.html
But you will have to manually iterate through all of the IP addrs on your subnet to get them to respond.
Why not just look at the ping source ;)