I am working on a project involving correlations in distance of the server in relation to pings and traceroutes. So I am getting the number of hops and the average ping time for different web sites. I am using puTTy and unix code to achieve this, when I traceroute the website (traceroute australia.gov.au -m 255) I allow for the maximum number of hops. I get about 18 hops, and then i get 237 numbers with three asterisks next to them. At first I assumed that this was a result of the -m 255 extension to the command, but it doesn't occur with websites like youtube or google. Is this timed out hops/connections? Also when i ping this website (ping australia.gov.au -c 25), I get no respsonse for about a minute (near 2000ms) and then the print out says that 25 packets were sent and 0 were received, what is the explanation for this?
Lots of places all over the internet block ICMP, meaning that australia.gov.au might have a valid routable IP, but just doesn't send back echo reply.
Three asterisks line from traceroute, as far as I can remember, means a packet with given TTL did not get a reply. That again probably indicates that the host/router does not want to be bothered replying to arbitrary ICMP and/or UDP packets.
Related
I got the first three records when I run command 'telnet 192.168.10.109 802' in my mac, then I key 'quit' to the telnet, and I got the next three records. Most people say tcp connection termination need 4-way-handshake, other words the fifth record should be sent in two parts, but this is not the case with my experiments. what is the truth of the case?
wireshark picture
I have found a answer in TCP/IP Protocol Suite, as shown in the picture
picture
I am doing host discovery only (-sn) option, trying to determine active hosts that are up and running.
My first command was:
nmap -sn -PS21,22,25,53,80,443,3389,8000,8080,42000 -PA80,443,8080,42000 -PU53 xxx.xxx.xxx.xxx/27
I am scanning public IP's and the above command produces a result stating that 18 hosts are up.
However, when I run the above command with --data-length "option" (either 32 or 56), it produces a result with only 8 hosts up.
I was expecting to see more hosts, if anything... but not less. (The data-length option adds a bytes of data to every packet to simulate the ping tool and it may help evade firewall rules set to drop 0 byte packets).
I am reading Fydors book however I am having trouble understanding the behavior above.
Any ideas?
Thanks
--data-length adds data to every packet. Your TCP discovery options (-PS, -PA) are sending packets that do not usually contain data. In this case, these packets are more likely to be dropped or ignored since they are unusual. The case where --data-length is useful is for the -PE (ICMP Echo Request) discovery option. ICMP Echo Request datagrams are usually sent with some data payload, but Nmap defaults to empty probes, so IDS products like Snort will sometimes block or alert on these probes.
I am designing a simple protocol on top of UDP and now I've realized that someone else can send a packet to the port I'm listening on. Such packet will obviusly be incorrect for my application (I'm not concerned about security now)
Is there the way of filtering these invalid messages? I was thinking about adding some fixed magic number at the beginning of each packet, but how large should it be? Is 16 bits enough?
I believe the typical solution is to require a handshake (that could include a "long enough" magic number) in the beginning of the session. Of course the "session" is something your protocol needs to keep track of, UDP does not have the concept. Keeping a list ip, port and last packet receive time for all current sessions should do it: then you can drop all packets from a peers that have not done the handshake beforehand. This not only prevents random unknown app traffic from breaking your application but will also prevent multiple legitimate peers from screwing up each others traffic.
Additionally you could add either a session id or an increasing packet sequence number (with allowances for missing packets) to packets if you need to ensure that the peer agrees with you on which session this is.
Probably. Java uses 32 for .class files (0xcafebabe). But you only have 534 bytes in practical UDP so you might need to save a couple.
I have recently set up this configuration: http://pastebin.com/9SWpqQnz
It is achieving the goal of having the route fail over to the backup ADSL line when the primary fibre ethernet line goes down.
It is, however, failing over for a short period of time every few hours or so.
I assume it is looking for a single missed ping?
Can anyone suggest how this might be tightened up a bit and made more reliable?
track 1 rtr 123 reachability
delay up 60 down 20
ip sla 123
icmp-echo 37.77.176.177 source-interface FastEthernet0/0
timeout 2000
frequency 10
ip sla schedule 123 life forever start-time now
Also it's probably worth pinging something a little further out on the internet, since your ISP could have issues that leaves your local loop up and running but the rest of their network is unable to forward traffic correctly. On the other hand, if you continuously ping something random on the internet that you don't have authorization for you could get blocked or rate-limited, which will artificially fail over your default route.
Traceroute is an application to trace the path from A to B. (A is your location and B is the server you want to trace). In Windows, you can type tracert. The main algorithm is:
send UDP with TTL = 1
Server A1 received, and return ICMP packet to A because TTL is expired.
--> know first machine between. For example A1.
send UDP with TTL = 2
Server A1 received, and send this UDP to server A2.
Server A2 received, and return ICMP packet to A because TTL is expired
--> know second machine between. In this example is A2.
Do it until to B. we can track down: A -> A1 -> A2 -> ... ->B
Does this algorithm work correctly? Because at different time, an intermediate server can send a message to different server. For example, at first time, UDP message is sent to A1, but at a later time, it can send to another server, for example, B1. So, trace route will not work properly.
Did I misunderstand something?
From the man page :
traceroute tracks the route packets take from an IP network on
their
way to a given host
So if you are trying to find one of the possible paths your packet may take, you'll find a friend in traceroute .
Now because routing tables do not change every minute, the packets that you send will most probably take the same path as traced by traceroute.
Another important point that cannot be missed is the record route option in the IP v4 header.
Once you specify that you want to use this option, every router in the path will add it's ip address to the options in the header. You can read more about it here. The catch being that the destination gets to know about the intermediate hops , not the source.
I see that you missed the role of icmp echo request and reply messages in the description of traceroute. In case this was not intentional , take a look.
Update : You can see the record route option in action by doing a ping -R
ping -R Turns on route recording for the Echo Request packets, and
display the route buffer on returned packets (ignored by many
routers).
The algorithm works properly. Indeed, routing may change due to considerations of different servers along the way, such as server load or availability. Let's say you want to send message from A to B. If the route is not changeable, what will happen if some server on the route is down? If the routing couldn't be adjusted dynamically, that would result in inability to deliver the message to the destination in this example. Here is a different example: let's say you have a server that is used for some heavy computation during the day but it's idle during the night. It's possible to allow it to pass traffic only during the night, so any routing using it will need to be changed at day.
To conclude all this we can definitely say that without dynamic routing the internet couldn't have existed in its' present form.
Addition:
Tracert sends message from A to B. It shows hops along the way. These hops constitute a valid route from A to B at the time of the execution. There is no guarantee that connection between 2 adjacent points along the way is valid after the hop has been completed. The only thing guaranteed is that for each hop there was a link between it's 2 endpoints when the message sent by tracert passed there.