Carniverous19 / helium-DIY-middleman

Code here acts as a middleman between LoRa gateways running Semtech packet forwarders and servers ingesting packet forwarder data
37 stars 41 forks source link

Need support and instructions for one physical gateway forwarding traffic to multiple miners #4

Closed simeononsecurity closed 1 year ago

simeononsecurity commented 2 years ago

I'd like to see support for one running multiple instances of the virtual gateway on one machine and only having to have one LoRA Gateway forwarding traffic to the middleman and middle man being able to forward that data to multiple miners. Additionally multiple gateways one each to multiple miners.

kissste commented 2 years ago

I'm working on almost exactly the same thing. Multiple Lora Gateways feeding one or many miners.

simeononsecurity commented 2 years ago

I'm working on almost exactly the same thing. Multiple Lora Gateways feeding one or many miners.

Well when you have something please link me

alexevictor commented 2 years ago

I'm working on almost exactly the same thing. Multiple Lora Gateways feeding one or many miners.

have u any result on that?

kissste commented 2 years ago

It's working well. Multiple RF Lora Gateways to Multiple Miners.

simeononsecurity commented 2 years ago

I won't say exactly how do to it. But the repos to do it are the following. https://github.com/simeononsecurity/helium-DIY-middleman

and either https://github.com/simeononsecurity/chirpstack-packet-multiplexer or https://github.com/simeononsecurity/samplicator

YMV Good luck

alexevictor commented 2 years ago

in any way can work many miners 2 many miners?

alexevictor commented 2 years ago

thnks anyway, only i ask

sblanchard commented 2 years ago

I've got this working to a point the packet forwarder logs packet-forwarder INFO: [up] PUSH_ACK received in 1 ms packet-forwarder INFO: [down] PULL_ACK received in 6 ms but the blue light (sensecap m1) turns to a fast flast meaning no connection to helium network. I had the same behaviour with it running on the device and also this software running on a pc. Any ideas? @simeononsecurity you seem to be the man. Does this still work on the new software releases?

simeononsecurity commented 2 years ago

I've got this working to a point the packet forwarder logs packet-forwarder INFO: [up] PUSH_ACK received in 1 ms packet-forwarder INFO: [down] PULL_ACK received in 6 ms but the blue light (sensecap m1) turns to a fast flast meaning no connection to helium network. I had the same behaviour with it running on the device and also this software running on a pc. Any ideas? @simeononsecurity you seem to be the man. Does this still work on the new software releases?

Not here to provide support for this one. Seems you have a configuration issue outside of the software anyways.

sblanchard commented 2 years ago

To answer my own question, it is gateway-config causing the problem and using a 6 month old version solved the problem

flash008a commented 2 years ago

@simeononsecurity , do you have the latest version of this gateways2miners.py? Or is this the latest you got on this GitHub?

sblanchard commented 2 years ago

@flash008a i've fiddled around with this, some problems is that most packet forwarders have the same mac address in their config - AA555A0000000000...which messes up the internal handling by mac address...the frequency/channel calculation only supports 915 which messes up the chan field on other frequencies like 868 (if you're on 915 don't worry)

it can be useful to log all messages to see if comms are happening.
in the

if msg['NAME'] == messages.MsgPushData.NAME: self.handle_PUSH_DATA(msg, addr) elif msg['NAME'] == messages.MsgPullResp.NAME: .... else: self.vgw_logger.info(f"received from {addr} {msg['_NAME_']}")

flash008a commented 2 years ago

middleman_args="--tx-adjust 0 --rx-adjust" doesn't seem to work, either.

simeononsecurity commented 2 years ago

Please keep comments relevant to the issue on hand. Otherwise start your own issue.

jibjab99 commented 1 year ago

This is already how it worked? However, it is no longer working due to miner updates.

simeononsecurity commented 1 year ago

This is already how it worked? However, it is no longer working due to miner updates.

It's still a powerful tool for relaying lora communications. Also this tool is definitely a 1:1. It can not forward to multiple miners/gateways without the help of other software.

proxynetul commented 1 year ago

This is already how it worked? However, it is no longer working due to miner updates.

It's still a powerful tool for relaying lora communications. Also this tool is definitely a 1:1. It can not forward to multiple miners/gateways without the help of other software.

Can you please fix this to work with new updates ? it no longer send beacons, wintess is ok

simeononsecurity commented 1 year ago

This is already how it worked? However, it is no longer working due to miner updates.

It's still a powerful tool for relaying lora communications. Also this tool is definitely a 1:1. It can not forward to multiple miners/gateways without the help of other software.

Can you please fix this to work with new updates ? it no longer send beacons, wintess is ok

Not a developer on this project. Submit a separate issue

proxynetul commented 1 year ago

This is already how it worked? However, it is no longer working due to miner updates.

It's still a powerful tool for relaying lora communications. Also this tool is definitely a 1:1. It can not forward to multiple miners/gateways without the help of other software.

Can you please fix this to work with new updates ? it no longer send beacons, wintess is ok

Not a developer on this project. Submit a separate issue

i know that, but probably you shoud know to that :) no one offer future update.