Shark Wifi Connection

[Gaja Starks]

Checkto ensure that the eth0 interface has an Internet connection. If the IP address is statically assigned to 172.16.24.1, rather than an address on the target network via DHCP, run the NETMODE DHCP_CLIENT command and try UPDATE_PAYLOADS again.

What Shark Jack are you using? The battery based "1st gen" Shark or the Shark Jack cable (SJC)? As I write this I see that you mentioned 1.2 in the title of the thread/post which indicates that it is the SJC that is being used.

How are you connecting to the Shark? You say that you can't find the Shark when looking at DHCP leases on your network but at the same time you say that you are able to execute the UPDATE_PAYLOADS command on the Shark which implies that you have local access to it. My guess is that you connect to it using serial via USB-C.

In what way did you prepare the Shark to act as a client to your network using DHCP? Did you create a payload including NETMODE DHCP_CLIENT and then set the Shark switch in attack mode before plugging it in?

3. I am able to access it and run the command, correct. My expectation was that the shark would grab a DHCP address when I plugged it into the computer. When I saw this was not the case I ran just the NETMODE DHCP_CLIENT command and that is where I lose access to the shark.

I did not do this, I have not created nor uploaded any payloads other than the default nmap script. Since the USB NIC I have plugged into my PC is showing as an adapter in control panel I figured the shark would automatically pick up a DHCP address when I ran the NETMODE command, but then that leaves the issue of figuring out what IP address it got so I can SSH back into it. I ran a network scan on my PC to try and find the shark after running the DHCP command but it did not appear to show up.

Instead of attaching the Shark to the PC, create a payload where it acts as a DHCP client from start and connect the Shark to some Ethernet port if you have any. The port should be in some networking device such as a "home router", switch or such that provides access to your network (and furthermore, the Internet). Then you can search for it on your network and connect to it using ssh. When in an ssh session, you can execute the upload payloads command. Another way (than searching for it on the network) is to connect to it using serial at the same time as it's connected to your local network and interact with the Shark that way.

Use a payload like the one below that will start as a DHCP client and also start the ssh daemon on the Shark to allow terminal logins. You can skip the code below the line that starts sshd though. That part is not needed.

I'm not using most of these extra tools since I'm doing things in other ways, so when reading the docs, I understand that it might be a bit confusing. When reading the docs about the UPDATE_PAYLOADS command, it has to be read in the perspective that the interaction with the Shark is supposed to be made using serial. If you are in arming mode and connected to it using ssh over Ethernet and you issue the NETMODE DHCP_CLIENT command, it will totally crash your ssh connection to the Shark and also the Sharks ability to communicate to the outside world since the PC can't provide a DHCP lease. In any case, the Shark needs to be connected to an Ethernet port that provides network and internet access. Connecting it to a PC won't make that happen.

Ah. So if I connect the USB C end to my PC, connect to it via serial (using PuTTY), and then plug the other end into my router, I should be good to go as far as getting it internet access? I will try this as soon as I can.

I've scoured the internet and forums for several days and can't find a specific match on this scenario. Upfront, I am pretty sure I know what the problem is, but I don't understand why it gets there when it does. My Orbi is an RBR40 and two satellites on covering three floors of my house and outside patio area. Setup has worked great for almost two years with no complaints from the family.

So, I bought this Shark Robot IQ . I read reviews and knew I had a 2.4 Ghz with Orbi, so no problem on that requirement. I set up the Shark Robot IQ via the Iphone app and Shark robot connected perfectly. I scheduled through the app a run through the house - no problems. About day or two after all this, I lost connection to the robot. So, as instructed by Shark, I turn off the robot, turn it back on, put it back on the dock - poof - wifi is back up and running. I tell the robot to clean - no problem. It runs through the main floor of the house and docks back to the station. Next day, I notice the robot is disconnected again.

That's when the hunt for a solution began and found issues with mesh networks. The problem I have doesn't seem to match most problems I've found. I actually do connect to the wifi and never have issues while running the vacuum on wifi. I've even left the house and checked on the robot while away on my iphone and it still is running on wifi. I've moved a satellite around, I've tried various changes to Orbi settings, and the same results occur. The iphone always connects to the 5 ghz band and robot obviously hooks up to the 2.4 ghz band, so the two are obviously communicating despite the band variance.

I am defeated at this point and raised the white flag. I've not reached out to Shark yet although I have a feeling they will point the finger back at the mesh network. I am not about to crack the Orbi and split the SSID as it seems to defeat the purpose of the mesh network. I'll likely just keep flipping the switch and running the vacuum that way as a minor inconvenience. I just wanted to hear from the forum on what explanation could it be that all is connected for a period of time and then just drop off like it does.

If you have an old router sitting around (even a wireless g/n one, the shart doesn't transmit much data), connect it and run it in AP (access point) mode. Just put the AP on a different ssid/wireless so it doesn't interfere with the orbi.

At the ethernet packet level, I can only see packets between my router and my computer. At the IP address level, I can only see packets with my computer's IP address as either the destination or source address. I can't see any communications between the router and another computer (at the ethernet packet level) or between any 2 other computers on my network (at the IP address level). And this is despite the fact that I put a tick in the check box for promiscuous mode, for my wi-fi adapter in the Wireshark adapters settings, and made sure to select that adapter as my capture adapter. An yes, I'm using the latest NPCap driver installed by the Wireshark installer.

I'm not sure what's wrong. I'm guessing it may have something to do with the fact that my router is using WPA2 encryption, instead of being unencrypted (like an "open" wireless network). Or maybe I need to use a wired connection (rather than wireless connection) when connecting my packet inspection computer to the router. Can anybody here tell me what's wrong? And how do I fix it?

Hello everyone. I have similar issues, that just did not occur in the past.Before I could packet sniff easily. & then for a long time, I didn't use it.Now with 2 different Alfa Adapters (I heard that the Atheros Chipset was better to use....so I bought it)Neither works in Ubuntu, using monitor mode etc.Recently I have wondered if it is possible to sniff with Windows 10.Again no luck, and I tried another packet sniffer (NetworkMiner), I installed Ncap Drivers, which did not work. so I tried a TP-Link Driver, and it worked normal....but still cannot sniff....in Monitor mode & Promiscuous mode.

Ethernet and Wi-Fi are different here, even though, if you're not in monitor mode - even if you're in promiscuous mode! - the packets you see will be "faked" Ethernet packets, with a fake Ethernet header constructed from the Wi-Fi header (Wireshark doesn't do that, the adapter and its driver do that).

For Ethernet, the most likely reason why other hosts' packets don't show up in a capture is that the capture is being done on a switched network. See the Wireshark Wiki's page on Ethernet capturing for a discussion of this.

For Wi-Fi, the most likely reason is that you're not capturing in monitor mode, which is the only mode that supports capturing third-party traffic; promiscuous mode does not support that on Wi-Fi. See the Wireshark Wiki's page on Wi-Fi capturing for a discussion of this, and note that, on a "protected" network, using WEP or some version of WPA, you will also need to have Wireshark decrypt the captured packets. See the Wireshark Wiki page on decrypting 802.11.

Furthermore, I had assumed that Monitor Mode was only needed to capture packets to networks you were not connected to, that is not connecting to any network at all and simply "sniffing" wifi packets out of the air and capturing them as raw wifi packets (and then from there capturing the ethernet packets within, and deeper layers if available, assuming that the wifi packet itself was not encrypted which would otherwise prevent deeper capture).

Very interesting. Are there any adapters that DO allow promiscuous mode, without monitor mode, in Windows? I don't (right now) have any particular need to sniff packets from networks I'm not connected to, but I would like to be able to monitor all packets on my current network (which theoretically only requires promiscuous mode, and not monitor mode). And yes my network is open (not encrypted), but it still seems that promiscuous mode is crippled and behaves just as if it were in normal mode (WireShark only shows packets who's source or destination is the computer performing the packet sniffing).

Based on that wiki article, it sounds like this problem is a Windows thing, and that my idea would work fine in Linux, but it also sounds like it has something to do with which wi-fi adapter I'm using. Maybe you could point me to a ...(more)

3a8082e126