ESP8266 Community Forum

- Thu Jul 02, 2015 11:42 pm #22310 Indeed that tool was helpful, not in figuring out what it did, but in so far as realizing how badly I needed to give up and look for another "in". I was able to get that by subscribing to the TX callback and taking a really close look at the buffers it was dealing with. Eventually, I found the buffers that get shoved out along with information like how big the buffer is.

I tested this against my laptop and it seems to send a raw packet successfully.

https://github.com/cnlohr/esp8266rawpac ... _rawsend.c

NOW!!! If someone can figure out how to go into promiscuous mode while connected to an AP, that would be a real winrar there. I'd give you 4 charles points.

- Fri Jul 03, 2015 12:48 am #22315 Do you insist on being connected to a AP while entering promiscous mode?
It looks like code can enter promiscous mode https://github.com/ly0/esp8266-smartlin ... martlink.c
If that does not work when connected why not disconnect, collect data, reconnect?

Cal

Get your modules here:

https://www.banggood.com/custlink/KvGGhGF4wG

- Fri Jul 03, 2015 1:04 am #22319 No, for my application, it is critical to perpetually be in both modes simultaneously. I don't need to hop channels or anything, and don't mind if I drop my packets periodically.

- Fri Jul 03, 2015 12:36 pm #22367 I've gotten a little further down this rabbit hole.

It seems I can enable the promiscuous mode while I am still an AP by calling wdev_go_sniffer, HOWEVER, it seems to prevent any packets from entering the 802.11 engine then. So, in the promiscuous callback, I used this neat function to stack dump.

Code: Select all   for( i = 0; i < 20; i++ )
   {
      ets_sprintf( ct, "  %p\n", *((&i)+i) );
      uart0_sendStr( ct );      
   }


And tracked it back to here... It seems the callback is actually called by ppProcessRxPktHdr, but, it looks like this function has nothing to do with processing packets normally, so I'm trying to find the normal packet path, so I can manually call the function that hands the packets off to the 802.11 stack, but alas, there are no references here, and the next thing up on my stack, 0x402459c0... Scratch a Bit pukes all over and can't interpret because of so many unkown opcodes. I have no idea how I'd progress from here...

P.S. the beqz is checking to see if there's a callback, if not, it frees buffers and immediately exits, so I /really/ need to know what lies right after this function in 0x402459c0 if I want go call the 802.11 receive function.

Code: Select all┌──────────────────────────────────────────────────────────────────────────│40245884                       ; xref: 0x4024588f r
│40245884          dat_40245884:
│40245884 a88cfe3f     dd      0x3ffe8ca8
│40245888          ppPeocessRxPktHdr:
│40245888 12c1f0       addi     sp, sp, -0x10     
│4024588b c911         s32i.n   a12, sp, 0x4
│4024588d cd02         mov.n    a12, a2       
│4024588f 21fdff       movi*    a2, 0x3ffe8ca8 ; via 0x40245884
│40245892 0901         s32i.n   a0, sp, 0x0                                   
│40245894 0802         l32i.n   a0, a2, 0x0                                   
│40245896 169004       beqz     a0, loc_402458e3                   
│40245899 320c01       l8ui     a3, a12, 0x1                                 
│4024589c 020c04       l8ui     a0, a12, 0x4                                 
│4024589f 303641       srli     a3, a3, 6                                         
│402458a2 9c03         beqz.n   a3, loc_402458b6                     
│402458a4 004741       srli     a4, a0, 7                                       
│402458a7 261449       beqi     a4, 0x1, loc_402458f4             
│402458aa 005064       extui    a5, a0, 0, 7                                 
│402458ad e68543       bgei     a5, 0x8, loc_402458f4             
│402458b0 620c07       l8ui     a6, a12, 0x7                                 
│402458b3 67e63d       bbsi     a6, 6, loc_402458f4                 
│402458b6                       ; xref: 0x402458a2 j                             
│402458b6          loc_402458b6:                                                   
│402458b6 720c0c       l8ui     a7, a12, 0xc                                 
└────────────────────────────────────