I've got an embedded system that just sits their waiting for incoming TCP/IP comms. It's got a static IP address. Do I need to actually set a subnet mask and gateway address as the system NEVER talks out other than when it is talked to?
If I do, please explain why.
Thanks,
Stuart
You can sometimes cheat and do such a thing with IP. The mac addresses should be there, assuming no broadcast, and the ip header has the source/destination, you can flip both around and the ports. You would still need to respond to the ARP looking for you, but the cheat is not sending an ARP looking for them basically ignoring the timeout. To do it correctly you need to keep a table locally and a timer and if you have never seen that ip address or the last time you saw it was more than a minute ago or whatever your timeout is, then you need to ARP for it to be able to respond. TCP is a much larger pain in the ..., with UDP you can do this kind of thing quite easily, swap macs, swap ip, swap ports, fill in the payload, checksum if you want or not, and send it back. Put code in to respond to the ARP. Dont see off hand why TCP would be any different.
Now assuming you are talking about some operating system, embedded or otherwise with a full stack, then that stack is likely going to want that information, but it is operating system/stack specific as to whether you can put bogus numbers in or not for situations where they dont need to be examined to respond to a particular connection. Of course that is not a programming question and this is a programming site, so I assume that is not what you are asking.
Related
I'm struggling to get an embedded platform with fairly standard IPV4 networking running. I have a working prototype which obtains an IP via DHCP without problem on a point to point connection (single cat5 cable) attached to a test laptop.
On my new hardware I get the link up but no DHCP request gets to the server (monitoring with wireshark). However what I do see, 100% repeatable, when those packets should be received, is a couple of ICMPv6 packets from the test laptop. This happens every time, there is no other activity on that link at any other time.
It seems to me that those packets are trying to tell me something, but what? Perhaps the DHCP request is going out but malformed for some reason?
(I can't post the actual packet from my phone, will make a copy and do so later.)
Seems to be something generated by the laptop when it sees the link comes up. Turned out to be unrelated to the issue I had (which was hardware related).
I was reading that in order to capture traffic for more than just my machine I need to put the nic into promiscuous mode. By default the nic seems to filter out the packets which are not meant for it.
My Question is : How come my nic even receive traffic that is not intended for it? Isn't my router supposed to route packets only to the computer for which it is meant?
Sorry - newbie here and this may be an absolute down votable question that I am asking.
I have heard that in case of wireless networks, the traffic takes multiple paths and the NIC combines these signals to form the original signal. So when a NIC sends something to the gateway it will send multiple signals and some if not all may even be captured by your packet sniffer.
Monitor mode also works like this
The short answer: It depends. :)
Wireshark Wiki: Ethernet capture setup should be of help to get you started.
I am person trying to learn networking. I understand that this may not be the best first step to take, but I am eager to try and understand how this takes place because it has been tearing up my mind for quite a while now.
My question is, how does a network recognize a device and automatically connect it to the network?(This is assuming, of course, that you have connected to the network previously and are connecting wirelessly.)
Does it store it on the routers side and then look for specific MAC Addresses and then connect it? Or is it stored somewhere on an encrypted file on your computer? Or is it none of these? Please forgive me if I am way off, I am only giving guesses from what I have so-far learned from networking.
'Connect it to the network' doesn't really mean anything, other than just plugging it in, or turning it on in the case of Wifi. What really happens is that the device broadcasts a DHCP request for an IP address, or else It already has an IP address in that subnet. From that point on it is discoverable by ARP, so other hosts in the subnet can send to it.
In my college lab, all the PCs are connected via a hub. I want to capture data packets using Wireshark, but it only displays the interface of my own PC. How can I capture the packets of other PCs?
I've tried all the interfaces, and I can't get it to work.
Odds are you're connected to a switch rather than a hub. The problem there is that only packets intended for your network card's hardware (MAC) address and broadcast packets will be sent to your PC. The switch remembers the hardware address of devices plugged into it and performs packet forwarding based on those addresses. This vastly increases the potential bandwidth of your network segment, but makes snooping on other traffic more difficult. You will need to perform what's called ARP cache poisoning. Basically you need to trick every other computer connected to the switch to send its traffic to you rather than its true destination. You will then need to forward those packets not actually for you onto the correct destination otherwise it will take down the entire segment you're on and people will get nosy.
This type of redirection is possible, but it seems like you'll need to do quite a bit more research and understand exactly what is going on before attempting it. To get started, look into the Address Resolution Protocol; understand what a "layer 2" switch is doing; find out how to inject and reroute packets on the network; think about the consequences of getting caught.
If you're serious about moving forward, check out http://www.admin-magazine.com/Articles/Arp-Cache-Poisoning-and-Packet-Sniffing for some starting tips.
When two computers are set the same ip address in a LAN(such as 192.168.1.100), both of them may receive incomplete packets. How does tcp on them react to this situation ? Will they ask for retransmission ?
My understanding is that TCP will reset the connections because of sequence number errors. So, connections will mysteriously and randomly disconnect, depending on when the stack detects the sequence number error.
You have two situations that can occur from this, one of the computers will be able to communicate fine while the other cannot at all, or they both will not communicate (if it stored the MAC ADDRESS in the ARP cache it will still try to route to the first computer on the network). Also, depending on the direction, if a computer that does not have a duplicate address trying to contact one of the duplicates, it will not the correct computer because they will be fighting over who has the ip address. If you swap that scenario, it will be asking for re-transmissions but no guarantee that it will ever get them, which leads back to them fighting over the response of who do I send it back to.