Re: [tcpdump-workers] rpcap support on non-windows

2017-03-02 Thread Joerg Mayer
Hello,

On Wed, Mar 01, 2017 at 05:50:57AM +0100, Joerg Mayer wrote:
> I'm trying to get libpcap working on macOS.
...
> Trying to understand the problem it looks like accessing struct pcap_md (the
> rpcap specific stuff) is broken on non-win32 platforms (or at least on bpf
> platforms).
> 
> The intended memory layout seems to be:
> 
> struct pcap_t (containing a pointer to priv if it exits)
> priv:
> struct pcap_
> struct pcap_md (if compiling with HAVE_REMOTE)
> 
> The current implementation seems to
> 
> a) only allocate the memory for pcap_md on win (pcap_create_interface() in
>pcap-win32.c), thus causing an out of bounds access on other platforms.
> b) the access to pcap_md is calculated as priv + sizeof(struct pcap_win)
>on all platforms which gets redeclared in pcap-new.c and pcap-rpcap.c
>for just this purpose. This looks wrong to me but I'm not sure.

OK, I think I managed to fix this one. Please see attached patch.

Now it fails (i.e. it no longer crashes!) with:
jmayer@newegg:~/worktmp/libpcap/build(master)$ dumpcap -i 
rpcap://10.122.4.11/wifi0
Capturing on 'rpcap://10.122.4.11/wifi0'
dumpcap: Invalid capture filter "(null)" for interface 
'rpcap://10.122.4.11/wifi0'.

That string isn't a valid capture filter (not-yet-activated pcap_t passed to 
pcap_compile).
See the User's Guide for a description of the capture filter syntax.

jmayer@newegg:~/worktmp/libpcap/build(master)$ dumpcap -i 
rpcap://10.122.4.11/wifi0 -L
Data link types of interface rpcap://10.122.4.11/wifi0 (use option -y to set):
  DLT -3 (not supported)

Both of which seem to be libpcap problems (or symptoms of the same problem).

Kind regards
   JÖrg
-- 
Joerg Mayer   
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
Fix access to struct pcap_md on non-Windows

Previously it was assumed that pcap_md was at offset pcap_t + pcap_win.
That assumption was only correct on Windows systems.

Signed-off-by: Joerg Mayer 
---
 pcap-int.h   |  3 +++
 pcap-new.c   |  4 ++--
 pcap-rpcap.c | 20 +---
 pcap.c   | 18 +++---
 4 files changed, 29 insertions(+), 16 deletions(-)

diff --git a/pcap-int.h b/pcap-int.h
index 5c8c129..e74eec8 100644
--- a/pcap-int.h
+++ b/pcap-int.h
@@ -178,6 +178,9 @@ struct pcap {
int break_loop; /* flag set to force break from packet-reading 
loop */
 
void *priv; /* private data for methods */
+#ifdef HAVE_REMOTE
+   void *priv_md;  /* private data for rpcap */
+#endif
 
int swapped;
FILE *rfile;/* null if live capture, non-null if savefile */
diff --git a/pcap-new.c b/pcap-new.c
index 494e425..816f51d 100644
--- a/pcap-new.c
+++ b/pcap-new.c
@@ -940,7 +940,7 @@ pcap_t *pcap_open(const char *source, int snaplen, int 
flags, int read_timeout,
}
 
struct pcap_md *md; /* structure 
used when doing a remote live capture */
-   md = (struct pcap_md *) ((u_char*)fp->priv + sizeof(struct 
pcap_win));
+   md = (struct pcap_md *)fp->priv_md;
 
fp->snapshot = snaplen;
fp->opt.timeout = read_timeout;
@@ -994,7 +994,7 @@ struct pcap_samp *pcap_setsampling(pcap_t *p)
 {
struct pcap_md *md; /* structure used when 
doing a remote live capture */
 
-   md = (struct pcap_md *) ((u_char*)p->priv + sizeof(struct pcap_win));
+   md = (struct pcap_md *)p->priv_md;
return &(md->rmt_samp);
 }
 
diff --git a/pcap-rpcap.c b/pcap-rpcap.c
index f5f3fa5..51c07ae 100644
--- a/pcap-rpcap.c
+++ b/pcap-rpcap.c
@@ -216,7 +216,7 @@ static int pcap_read_nocb_remote(pcap_t *p, struct 
pcap_pkthdr **pkt_header, u_c
struct timeval tv;  /* maximum time the select() 
can block waiting for data */
struct pcap_md *md; /* structure used when doing a 
remote live capture */
 
-   md = (struct pcap_md *) ((u_char*)p->priv + sizeof(struct pcap_win));
+   md = (struct pcap_md *)p->priv_md;
 
/*
 * Define the packet buffer timeout, to be used in the select()
@@ -423,7 +423,7 @@ static void pcap_cleanup_remote(pcap_t *fp)
int active = 0; /* active mode or not? 
*/
struct pcap_md *md; /* structure used when 
doing a remote live capture */
 
-   md = (struct pcap_md *) ((u_char*)fp->priv + sizeof(struct pcap_win));
+   md = (struct pcap_md *)fp->priv_md;
 
/* detect if we're in active mode */
temp = activeHosts;
@@ -559,7 +559,7 @@ static struct pcap_stat *rpcap_stats_remote(pcap_t *p, 
struct pcap_stat *ps, int
int retval; /* temp variable which stores 
functions return value */
struct pcap_md *md; /* structure used

Re: [tcpdump-workers] Request for link layer header type

2017-03-02 Thread Erik de Jong
On Sat, Feb 18, 2017 at 10:25 PM, Erik de Jong  wrote:

>
>
> On Wed, Feb 15, 2017 at 6:04 PM, Michael Richardson 
> wrote:
>
>>
>> Guy Harris  wrote:
>> >> You are correct, the packets encapsulated by the LoRaTap format
>> will
>> >> be those from the PHYPayload as listed in section 4. This document
>> >> details the LoRaWan protocol which is something that can run on
>> top of
>> >> the LoRa radio phy layer. The LoRaTap could be of the LoRaWAN
>> protocol
>> >> or anything else one might want to send over LoRa radios.
>>
>> > So what other protocols, if any, would be sent over LoRa radios?
>>
>> > If there's more than one protocol, will any systems that are saving
>> > pcap or pcapng files containing LoRa packets know what protocol that
>> > is?  If so, perhaps there should be more than one link-layer header
>> > type, one for each protocol (even if they all share the same
>> > pseudo-header for radio information).
>>
>> Please plan for either subtypes, or multiple types.
>> There will at least, I think, be incompatible revisions to LoRaWAN!
>> (I've stopped paying attention to LoRA though)
>>
>
>
> I was thinking this over the past few days but I really can't find a good
> way to deal with that on a link-layer type base. The only proper way would
> be to define one LINKTYPE_LORATAP_RAW and another LINKTYPE_LORATAP_LORAWAN
> where the latter one could be parsed by analyzers as being LoRaWAN type
> traffic, this would imply for the capturing software to parse the data
> first and discard any that don't have a valid MAC header and/or correct
> MIC... There is of course the 'syncword' that is able to trigger an
> interrupt on the Semtech chips but that's not working when using a
> continuous reception mode which is what you'd use for making captures.
> Actually, why no work on an even more generic linktype for RF packets?
> That would work for this case as well.
>
> Also I think it will need channel and Rx strength containers.
>> (In a pure pcap-ng situation, it would be nice to have generic headers for
>> channel and signal strength...)
>>
>
>
> Good point! A container for channel would contain the bandwidth and
> frequency. For RX strength I'd suggest two fields, the RSSI and max RSSI
> like in Radiotap. While dissecting a basestation ('gateway') I've borrowed
> I've noticed it also reporting the antenna that received the packet when
> posting to the backend. However I think that might be something that's more
> appropriate for the interface description block like in pcap-ng and not for
> the captured packets. Having multiple antennas would basically just be the
> same as having a capture from multiple sources.
>


I have added containers for RSSI and Channel, also decided to introduce a
byte for the sync word. Packet analyzers can use this field to determine
which upper layer protocol to parse. Please find the latest revision over
on github (https://github.com/eriknl/LoRaTap).

Regards,
Erik
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers