Skip to content

promicous mode and wifi class , intended behaviour? #4682

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
6 tasks done
ZweiEuro opened this issue Apr 25, 2018 · 14 comments
Closed
6 tasks done

promicous mode and wifi class , intended behaviour? #4682

ZweiEuro opened this issue Apr 25, 2018 · 14 comments
Labels
waiting for feedback Waiting on additional info. If it's not received, the issue may be closed.

Comments

@ZweiEuro
Copy link

ZweiEuro commented Apr 25, 2018

Basic Infos

  • This issue complies with the issue POLICY doc.
  • I have read the documentation at readthedocs and the issue is not addressed there.
  • I have tested that the issue is present in current master branch (aka latest git).
  • I have searched the issue tracker for a similar issue.
  • If there is a stack dump, I have decoded it.
  • I have filled out all fields below. <- my core code is like 12 files.

Platform

  • Hardware: ESP8285 device
  • Core Version: latest git
  • Development Env: Arduino IDE
  • Operating System: Ubuntu

Settings in IDE

  • Module: Nodemcu
  • Flash Mode: ?
  • Flash Size: 4MB
  • lwip Variant: v2 Lower Memory
  • Reset Method: nodemcu
  • Flash Frequency: ?
  • CPU Frequency: 80Mhz
  • Upload Using: SERIAL
  • Upload Speed: 115200

Problem Description

Working on a node MCU E-12 .

I've been trying out promiscuous mode, as from the mini sniffer or spacehuhns project. I tried if it was possible to connect wifi while using this mode.
(after disabling promicous_mode, setting a new callback, and then reenabling it)
WiFi.status() kept responding 0 although that the connection didn't seem to be successful -> because, client.connect(WiFi.gatewayIP(); ,80); //tried it with my router first, both respond 0.

So, is this intended behavior? shouldn't wifi.status change it's status if promiscuous mode cancels it?

recalling Wifi.disconnect() and Wifi.begin() right after, on the same network, seems to get stuck indefinetly.

This works:

    Serial.println(WiFi.status());
    Serial.println("start udp");
    wifi_promiscuous_enable(disable);
    WiFi.disconnect(true);
    WiFi.begin(ssid, pw);
    wait_for_wifi();
    WiFiClient client;
    const int httpPort = 80;
    if (!client.connect(WiFi.gatewayIP(), httpPort)) {
      Serial.println("connection failed");
      return;
    }{
      Serial.println("success 80 ");
    }
      wifi_promiscuous_enable(enable);
    Serial.println("end udp");

So i have to disable promiscuous mode when connecting or using wifi. otherwise begin will get stuck and any connection tries will return 0.
I am guessing i can't use promiscuous mode while using the wifi normally. which seems a little odd since it doesn't seem like it gets in the way of normal traffic. If promiscuous mode just listens in on whatever floats through the air it shouldn't really matter if those packets are addressed to me.

And if it is a problem, shouldn't WiFi.begin scream if promiscuous mode gets or is enabled while it is called ?

@devyte
Copy link
Collaborator

devyte commented Apr 25, 2018

@DasVoelkel the behavior of promiscous mode is specific to the SDK, and not of the core libs in this repo. That means that it is currently completely unsupported. In addition, I am not aware of any developer with plans to support it in the foreseeable future.
If it is your intent to just gain information about how promiscuous mode works and how to use it, this is likely not the right place to ask. In this case please close this issue.
If it is your intent to figure it out, and contribute your findings here, e.g.: a working example, it would be appreciated. In this case, I can provide some info on the internals of this core, e.g.: point you to specific parts of the source code, or provide some insight about why some things are done the way they are.
Be aware that, for the most part, the WiFi handling code is a not-too-thick wrapper around the SDK api, so if you find weird things, they are most likely in the SDK itself rather than in this core.

@devyte devyte added the waiting for feedback Waiting on additional info. If it's not received, the issue may be closed. label Apr 25, 2018
@ZweiEuro
Copy link
Author

ah ok.
I didn't know there were no further plans to support it. I did know that it was specified in the SDK and i read through what i thought was important.
If the promiscuous mode is of no concern to the development of this projects (library) then you've answered my question in that both code parts where never considered to be run in the same place?
Meaning SDK's promiscuous mode and the WiFi functions were never considered to be run at the same time?

@d-a-v
Copy link
Collaborator

d-a-v commented Apr 25, 2018

Do you need promiscuous at the PHY level (radio) or Ethernet level (network) ?
For ethernet you can have a look to #4678.

@ZweiEuro
Copy link
Author

ZweiEuro commented Apr 27, 2018

I am kinda new to git, what exactly is #4678 ? I don't get anywhere with the info presented to me on that screen.
And yes i think i need it as an ethernet (wifi) radio.

@devyte
Copy link
Collaborator

devyte commented Apr 28, 2018

That is a PR (pull request) with a proposal of a new lib, which can capture ethernet packets. You can dump the packets (print them out), or do whatever you want.
So the question is valid: do you need to observe at wifi (phy) level, or at ethernet packet level?
For phy you likely need the SDK promiscuous mode, which we don't currently support here.
For ethernet packet traffic, you should test the PR and check if it is enough for you. In this case, feedback is welcome.

@ZweiEuro
Copy link
Author

For the purpose of capturing beacon packets. I think i need phy level.
I tried observing on ethernet level, sadly in an encrypted network this isn't much use. If i wanted more information out of the network i'd need access to the arp and ICMP protocols ,which is currently not supported.
So for my test case currently i'd need the physical switch.
In this case "not supported" regarding the promiscuous mode, means that it won't at all work as intended, or that some features may work and some may not because of no official support.

@d-a-v
Copy link
Collaborator

d-a-v commented Apr 28, 2018

With #4678 you can monitor arp packets if you are inside/connected to the WiFi network.
Regarding WLAN promiscuous "not supported", it is not supported here in esp8266/Arduino, we don't even use it. You need to ask your questions about that in espressif/esp8266_nonos_sdk which is our closed-sources vendor firmware.

@ZweiEuro
Copy link
Author

Monitoring arp packets would be great and even better would be the ability to send them myself.
If i wanted to use this other library and monitor arp packets, how would i go about doing that?
#4678 many different commits, so i need netdump and merge it with the esp8266master library? I am not really sure how i should go about using this, as i don't want to accidently break the library.

If monitoring arp packets is supported on here, how come i've not found anything in those regards in the library source code ?

@RudyFiero
Copy link

If monitoring arp packets is supported on here, how come i've not found anything in those regards in the library source code ?

And who said that? You are being a Dickhead. d-a-v has been very generous with his time in regard to your request. He has pointed you in the correct directions. He explained that the access you want is not part of the Arduino/ESP8266 framework but may be available from a lower level (that is not the code here) that you need to explore on your own. If you want to see what information is here regarding arp requests then use the search box. Have you even tried that? Because that is what is here. Nothing else.

arp

@devyte
Copy link
Collaborator

devyte commented Apr 29, 2018

Alright, let's keep things.civil here.
@DasVoelkel as I explained above, the packet capture PR is currently proposed, and not yet merged. It is meant for ethernet traffic which means packets exchanged between the ESP phy and lwip.
I am still unclear about whether you need the sdk promiscuous mode, as stated in the title, or if ethernet packet capture is enough for you.

@d-a-v
Copy link
Collaborator

d-a-v commented Apr 29, 2018

Testing this PR is welcome. Assuming you are using git, the instructions are

git fetch origin/pull/4678/head:netdump
git checkout netdump

then restart the arduino IDE, and you will find two examples in Files>Examples>esp8266>netdump>.

Just run the netdump.ino one, and you'll see all packets from and to the esp. It's of course better if these few lines are integrated into a proper arduino sketch doing something with the network.

edit: going back to master branch

git checkout master

@ZweiEuro
Copy link
Author

ZweiEuro commented May 1, 2018

Thanks a lot for the help! If i find issues with that build should i report them in a new issue?

@devyte
Copy link
Collaborator

devyte commented May 1, 2018

@DasVoelkel no, if you find issues in the PR, please report them in that same PR.

@ZweiEuro
Copy link
Author

ZweiEuro commented May 2, 2018

Thanks a lot fot the help! Sorry for not understanding everything right away!

@ZweiEuro ZweiEuro closed this as completed May 2, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
waiting for feedback Waiting on additional info. If it's not received, the issue may be closed.
Projects
None yet
Development

No branches or pull requests

4 participants