kismet
kismet copied to clipboard
kismetwireless
Mislabel 433 output
I've got rtl_433 more or less working inside kismet, but I notice some strangeness in the web ui. I have the following in my kismet_site.conf
source=rtl433-315:channel=315MHz,gain=60,name=TPM315 source=rtl433-433:channel=433MHz,gain=60,name=TPM433
But in the web ui, the 433MHz data shows up under the TPM315 drop down label. (I cant' tell if it's vise versa as I haven't picked up any 315MHz TPMs). I've verified via "ps ax" and "rtl_test" that all is running as it should as far as device indices, etc.
The physical type is named 'rtl433' so it will list them all under rtl433; you could view by source or sort by channel to get specific receiving devices (much the same way two wifi devices one on channel 1 and one on channel 6 are still wifi, everything using the rtl_433 backend is a rtl433)
On Tue, Feb 25, 2020 at 9:57 AM Matthew Clark [email protected] wrote:
I've got rtl_433 more or less working inside kismet, but I notice some strangeness in the web ui. I have the following in my kismet_site.conf
source=rtl433-315:channel=315MHz,gain=60,name=TPM315 source=rtl433-433:channel=433MHz,gain=60,name=TPM433
But in the web ui, the 433MHz data shows up under the TPM315 drop down label. (I cant' tell if it's vise versa as I haven't picked up any 315MHz TPMs). I've verified via "ps ax" and "rtl_test" that all is running as it should as far as device indices, etc.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kismetwireless/kismet/issues/223?email_source=notifications&email_token=AFKJYY3SM4NC6DUHTNIS7A3REUWVFA5CNFSM4K3LLEKKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IQDDYUA, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFKJYY7AK76C6IZ6U5PRUMTREUWVFANCNFSM4K3LLEKA .
Yes, if I use the rtl433 under "Phy Types" I can see both. I'm referring to the Data Sources, which shows the names I assign, it, TPM315. I expect to see 315MHz entries there as that's how I defined the datasource, but I'm seeing the 433MHz stuff, which I had given the name "TPM433"
What does rtl_test show as your device serial numbers? Are they unique?
On Tue, Feb 25, 2020 at 5:41 PM Matthew Clark [email protected] wrote:
Yes, if I use the rtl433 under "Phy Types" I can see both. I'm referring to the Data Sources, which shows the names I assign, it, TPM315. I expect to see 315MHz entries there as that's how I defined the datasource, but I'm seeing the 433MHz stuff, which I had given the name "TPM433"
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kismetwireless/kismet/issues/223?email_source=notifications&email_token=AAZAOCAGPKLTDY4MZ5B5XF3REWNARA5CNFSM4K3LLEKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEM5Z63I#issuecomment-591109997, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZAOCESPQRPU6AX3IPNBU3REWNARANCNFSM4K3LLEKA .
Found 3 device(s): 0: Realtek, RTL2838UHIDIR, SN: 315 1: Realtek, RTL2838UHIDIR, SN: 433 2: Realtek, RTL2838UHIDIR, SN: 1090
Using device 0: Generic RTL2832U OEM
So far I can't replicate; with two rtl433s, one set to 433 and one set to 315; the devices seen by the 433 are only shown associated with the 433 device.
Configured with -c rtl433-0 and -c rtl433-1:channel=315MHz
On Fri, Feb 28, 2020 at 4:54 PM Matthew Clark [email protected] wrote:
Found 3 device(s): 0: Realtek, RTL2838UHIDIR, SN: 315 1: Realtek, RTL2838UHIDIR, SN: 433 2: Realtek, RTL2838UHIDIR, SN: 1090
Using device 0: Generic RTL2832U OEM
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kismetwireless/kismet/issues/223?email_source=notifications&email_token=AFKJYY2JDALEGP7NPWWA4ALRFGB2TA5CNFSM4K3LLEKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENKJRUQ#issuecomment-592746706, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFKJYY3LP5OVSSWTIN72KW3RFGB2TANCNFSM4K3LLEKA .
Also try with the latest nightlies; there's been some bug fixes; none should have been directly related to this but you never know.
On Mon, Mar 2, 2020 at 10:19 AM Matthew Clark [email protected] wrote:
I'll try again to make sure.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kismetwireless/kismet/issues/223?email_source=notifications&email_token=AAZAOCDGWYX2W6FMK7QVRFLRFPE7XA5CNFSM4K3LLEKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENPWKGI#issuecomment-593454361, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZAOCC65C27GBMAAH5RV4TRFPE7XANCNFSM4K3LLEKA .
I just compiled and installed from a clone of github master this evening and I'm seeing something that may be related.
I think what's actually happening here is that devices detected by rtl433 are always being reported in Kismet as coming from channel 433.920 MHz, even if the real channel is actually something else. Maybe it was hard-coded somewhere by mistake.
My only rtl433 source is configured to use channel=315MHz. I'm only seeing one device entry at the moment in Kismet and it's listed in the web interface as channel 433.920 MHz. At first I thought it was failing to set the channel properly when it started the rtl433 source but I ran rtl_433 by itself, outside Kismet, with the frequency set to 315 MHz (using the -f flag) and it detects the same device with the exact same unique device ID. The device (a TPMS) wouldn't be transmitting with the same unique ID on both 433.92 and 315 MHz.
I also ran rtl_433 with the default frequency (433.92 MHz) and it isn't detecting any devices (probably just none within range). I did this just to confirm that nothing is really transmitting on 433.92MHz despite the way it's reported in the web-gui.
On a somewhat related note, Kismet isn't showing the pressure value for the TPMS device even though rtl_433 reports the value when run on its own. The temperature is showing but for some reason the pressure value isn't making its way into Kismet.
On a somewhat related note, Kismet isn't showing the pressure value for the TPMS device even though rtl_433 reports the value when run on its own. The temperature is showing but for some reason the pressure value isn't making its way into Kismet.
Is this still an issue?
I'll try again with the latest versions. Have there been any changes that would address this?
After running a bit longer using the version from my comment above, I noticed that some sensors reported pressures in Kismet and others didn't, so it might be some difference with how various RTL_433 protocol decoders format the data that gets passed to Kismet. That's just a guess though and I don't really know. The one I know I saw this issue with was a Toyota TPMS.