Open pmontrasio opened 7 years ago
Hey Paolo!
I was running epcap inside an Elixir program on a Raspberry PI 3 when I run into this error
** (FunctionClauseError) no function clause matching in :pkt_ether.type/1 src/pkt_ether.erl:37: :pkt_ether.type(34924) src/pkt.erl:120: :pkt.decapsulate_next/2
34924 is 0x886c. I googled and found https://www.raspberrypi.org/forums/viewtopic.php?t=146246&p=963226 If I understood that correctly, it's the builtin wifi card of the PI that is sending those packets. I don't know what a LARQ is and I don't really now what I've been doing, but this fixed that:
diff --git a/include/pkt_ether.hrl b/include/pkt_ether.hrl index 2412165..71107ba 100644 Thanks for figuring this out! That looks great.
The first binary is the destination MAC address, the second binary is the source MAC address and it looks like the next two terms could be the LARQ header followed by a pad.
The raspberry pi thread you linked to has the protocol details:
https://www.google.ch/patents/US20070263631
The header format:
https://patentimages.storage.googleapis.com/US20070263631A1/US20070263631A1-20071115-D00005.png https://patentimages.storage.googleapis.com/US20070263631A1/US20070263631A1-20071115-D00006.png
Could you provide a packet dump in pcap format? Feel free to anonymize it. You can email it directly or attach it to this issue:
michael.santos@gmail.com
Maybe it's not the Erlang way, but it could return
unknown
instead of failing when it doesn't know how to decapsulate something. The client would fail anyway if it doesn't handle that, or could decide to keep going on.
See pkt:decode/1,2. They'll return the decoded headers and the remaining binary on error.
I'm not very familiar with these tools and I'm not sure if I got any 0x886c packet in a dump I made with tshark -i wlan1 -w test.pcap -F libpcap
, nor I could find a way to create a capture filter for only those packets.
Running out of time I googled for them and I found this issue of Wireshark. There is a link to a pcap file with a 0x886c packet. Would that be good enough?
Thanks for the reference to pkt:decode/1,2
. I didn't notice that. Maybe I was cargo culting from some page that decoded packets using decapsulate
.
Thanks for trying! I'll have a look at the links, they look like a good start. I have to order an rpi3 anyway so I'll be able to add support for the other frames types then.
If you run into any more issues or have any questions, please feel free to let me know!
I was running epcap inside an Elixir program on a Raspberry PI 3 when I run into this error
34924 is 0x886c. I googled and found https://www.raspberrypi.org/forums/viewtopic.php?t=146246&p=963226 If I understood that correctly, it's the builtin wifi card of the PI that is sending those packets. I don't know what a LARQ is and I don't really now what I've been doing, but this fixed that:
It's probably a hack but I hope it helps adding proper support for these packets.
decapsulate
now returns something likeMaybe it's not the Erlang way, but it could return
unknown
instead of failing when it doesn't know how to decapsulate something. The client would fail anyway if it doesn't handle that, or could decide to keep going on.