-
Notifications
You must be signed in to change notification settings - Fork 182
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
Feature Request: Add Wi-Fi callback example #388
Comments
This is my non-working code. It seems the callbacks never get called. // Wrap your drivers in Arc<Mutex<_>> to allow shared mutable access.
let eth_mutex = Arc::new(Mutex::new(eth));
let wifi_mutex = Arc::new(Mutex::new(wifi));
// Clone the Arcs for use in closures
let eth_mutex_clone = eth_mutex.clone();
let wifi_mutex_clone = wifi_mutex.clone();
// Forward from eth to wifi
eth_mutex
.lock()
.unwrap()
.driver_mut()
.set_rx_callback(move |frame| {
info!("Forwarding frame from eth to wifi...");
if let Err(e) = wifi_mutex_clone
.lock()
.unwrap()
.send(WifiDeviceId::Sta, frame)
{
error!("Failed to forward eth frame to wifi: {}", e);
}
})?;
// Forward from wifi to eth
wifi_mutex.lock().unwrap().set_callbacks(move |_, frame| {
info!("Forwarding frame from wifi to eth...");
if let Err(e) = eth_mutex_clone.lock().unwrap().driver_mut().send(frame) {
error!("Failed to forward wifi frame to eth: {}", e);
}
Ok(())
}, |_, _, _| {})?; |
Hm, when callbacks are set the interfaces are stopped. |
The C functions are noted to be internal to ESP and not recommended for customers to use. Regardless, they seem to function. Better documentation is needed. |
I wrote a esp sniffer using the promiscuous mode and streamed the data via callback's as PCAP packets back over uart directly into wireshark on a host machine. I am telling you this because you need to be really careful using the callbacks. By that i am talking about that the callbacks are working inside the wifi thread with a high system priority. You should not do any blocking there as you will stale the complete wifi driver. Best is to just grab the data/info you want and just push it out. Don't use Mutex's that maybe can deadlock you or are to slow. Just stream out the data via a mpsc channel or something. At that time i didn't use this callbacks but the unsafe esp-idf-sys methods directly but it should be similar- |
Another development, the callback functions seem to be broken, there's a workaround in https://github.com/makischu/ESP_eth2wifi. |
The original purpose of these callbacks was not to do what you are trying to do (i.e., have the callbacks and the netif stack on top running together somehow), but to rather allow users to have a driver (eth and/or wifi) that operates purely on L2 level, and then potentially layer a user-provided IP stack layer on top of the callbacks. Say - the pure Rust With that said, I have not tried whether that would work, as I don't yet have that usecase, but I don't see why it wouldn't given that the ESP IDF netif layer uses these very same callbacks. With that said, your use case is different, so you probably need to inspect or even patch the netif stack so that callbacks or their equivalents are usable even when the netif stack continues to run on top. |
@ivmarkov Can I just patch the esp-idf sources in |
Just use your own esp idf git fork. You can pass the git url and/or the path to your local ESP IDF to esp-idf-sys. |
Is there a doc or somewhere I can read more directions for this? Sorry if I'm dense, this is my first endeavor into Rust on ESP32 (and the ESP32 itself for that matter). For anyone reading along, it looks like there's an up to date example here (sta2eth): https://github.com/espressif/esp-idf/tree/master/examples/network |
I'm trying to use WifiDriver::set_callbacks but I'm not successful. I think an example would be helpful.
Context: I'm trying to implement this in idiomatic Rust: https://github.com/dokmic/eth2wlan/blob/master/main/main.c
The text was updated successfully, but these errors were encountered: