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).
Related
Update:
I know, the WIFI AP is still on & active in this case and the chip should not know about the change, but the question is still open. How should I check the connectivity?
In my project, the internet connection is really important.
After some testing, I have experienced that if I plug out the ethernet cable from my router the ESP32 still thinks, that it is still connected to WIFI, even the
WiFi.status() == WL_CONNECTED
is always true in this case.
So, I have tried out pinging google.com to examine the connection. This works but takes ages to get back the result.
How should I check the connectivity with the lowest resource cost and time?
Even WiFi.status() is unreliable due to the not documented details by Espressif. The API is error prone as the issues on github show.So actually the question is . what do you really want to check? - in my definition internet connection means my line (or aerial) connectionto my ISP is unbroken. This includes
my AP
my router
the ISPs fiber converter in my basement,
the line itself and the
ISPs gateway
This is what I use to determine wether a connection is open. I ping the IP address of the ISP gateway server. So you save time (no DNS resolution, no hops over nodes on the internet. If you mean wether a certain service on a defined server is available, thats slow but then you are 100% sure.
Just a clarification: "ESP32 still thinks, that it is still connected to WIFI" - YES that has to be true because according to the API this ensures client to AP connection and not AP connection to some where else. Normally a good configured router informs its clients about connection loss (in this case the connected AP(s)) and these notify (depending on their config) their clients (or sometimes not or very late)
Technically that result is correct because you are still connected to wifi!
Just because you unplug the ethernet cable doesn't mean your wifi stops. All it means is that your wifi can't get to the internet.
You can try pinging your isp's dns server. It's a lot closer to you than Google is.
Just the ramblings of an old man...
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.
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.
One of my networks course projects has to do with 802.11 protocol.
Me and my parther thought about exploring the "hidden terminal" problem, simulating it.
We've set up a private network. We have 2 wireless terminals that will attempt to send a file
to a 3rd terminal that is connected to the router via ethernet. RTS/CTS will be disabled.
To compare results, we'd like to measure the number of packet collisions that occured during the transfer so as to conclude that is due to RTS being disabled.
We've read that it is imposible to measure packet collisions as it is basically noise. We'll have to make do with counting the packets that didnt recieve an "ACK". Basically, the number of retransmitions.
How can we do that?
I suggested that instead of sending a file, we could make the 2 wireless terminals ping the 3rd terminal continually. The ping feature automatically counts the ping packets that didnt recieve the "pong". Do you think its a viable approach?
Thank you very much.
No, you'll get incorrect results. Ping is an application, i.e. working at application (highest) level of the network. 802.11 protocol operates at MAC layer - there are at least 2 layers separating between ping and 802.11. Whatever retransmissions happen at MAC layer - they are hidden by the layers above it. You'll see failure in ping only if all the retransmissions initiated by lower levels have failed.
You need to work on the same level that you're investigating - in your case it's the MAC layer. You can use a sniffer (google for it) to get the statistics you want.
I'm using sharppcap in order to send packets as part of a monitoring system. Usually it works well but I've encountered the strangest bug on a hosted vista machine and I would like your help.
On that virtual vista machine, injected packets are duplicated. That is, if I send a ping request using libpcap, it somehow gets duplicated and I get two requests on the destination machine. The two requests are almost identical byte-wise, and the only difference between them is that the second packet's TTL field is one minus the original packet's value.
Using wireshark I can see the packet gets duplicated before it (and its clone) leave the vista machine.
The problem is manifested even when using other tools for injecting packets using libpcap (namely PlayCap).
Any ideas?
The TTL field being one lower on the clone packet indicates that it has gone through one more routing hop than the other packet. This seems to indicate that the packet has gone through the Vista machine's input packet queue (and is routed back out) as well as directly to its output queue.