Closed petrkr closed 6 months ago
Good question ... The adapter uses libmbus https://github.com/rscada/libmbus ... does it work with the binaries from there (Should be installable via apt install) ... then it would be more also an issue there. Else I need to find out what to change in the c++ code side for adding ipv6 support ...
Any help here appreciated because I'm far away from being a pro there. If you could verify if these binaries wotjk with ipv6 or not would already help.
Actually not, I tried almost year ago, I just overlook, you using this library.
I going from node-red mbus implementationc where also noone replied to that bug so i started littlebit investigate and I found they using this library, so i tested it, but as I overlook you using libmbus, so this BugReport is mostly for themc but they not even bother to reply since June.
So probably if I want use it in modern environment I will have to do it myself.
I think also they are limited on resources and simply someone is missing with the relevant knowledge for linux (and here windows) on how ipv6 is implemented differently ...
I need to find time to look intop that ... or someone there ... Sorry this will not be a "fast" solution ... But IPv6 only networks are still far away from being "common", I thinkthats why it is more "rare" issue
It starts to be common in some kubernetes environments. For me it is not because of ipv6 only network, but because lack of public IPv4 between node-red server and my mbus sensors. But everywhere is IPv6.
And I do not count VPN as solution, that is just workaround. If there is place (house etc) where is traditional cheap router, there could not be done VPN at all and buy another router/pc just because of that is littlebit overpriced. So I rather give some time to make solutions better than making workaround, like others.
You can see for example that libmbus has more tha 150 forks and someone even did nice changes, but noone made Pull request back.
but noone made Pull request back.
this is the "Not that funny part".
Honestly: If you like scan through them and point me to one that maybe did IPV6? ;-) maybe I can have a peek there or at least ask the guy to do a PR
PS: https://github.com/petrkr/libmbus/commit/a6297b406a5a2e6734552a6a1dda954ab41f393a ... then I assume you bring the PR? :-)) if it is not accepted by upstream I could tak it in my branch and include it so faster for nodejs
Since maintaner does not made any activity for 3 years, I assume it's dead project.
Since maintaner is some automatization solution, maybe thay guy no longer work at that company. Or since it's 2021 maybe something more bad happened. As you can see only 4 repos on that account and all without activity since 2021
Nooo donot assume this please. please do a PR ... if you like also do a PR on my fork - ideally the "build-windows" branch because I build from there ... I might need to check how to get ipv6 for windows then too ... but first look it is compatible code ;-)
Or since it's 2021 maybe something more bad happened
His name is lategoodbye, this is not an option
He merged a PR yesterday https://github.com/rscada/libmbus/commits/master/ ... ssooooooo ;-)))
maybe there is a momentum ... he merged PR where I reviewed too ... use the momentum and try a PR
maybe there is a momentum ... he merged PR where I reviewed too ... use the momentum and try a PR
I already fixing his review catches. Check https://github.com/rscada/libmbus/pull/213
awesome!
So IPv6 support was merged, I've retested it again. So you can update to that library and it should work out of box aswell
Yes already in the list ... might take some days :-)
Ok ... @petrkr
so in theory we should be done already :-) wanne try to test it? Please install from GitHub and git it a try. thank you!
hm ... ok linux and macos works ... ipv6 on windows not ... need to check why :-(
Like nothing (even ipv4) or only ipv6
I do not have windows, so I can not test that use-case
Ah it even not compile.
getaddrinfo' undefined;
You have some fork fork of win version or original can be compiled?
Asking because if fix should be done on upstream or this fork.
Problem will be, windows need to include winsocks headers.
So there should be something like ifdef windows, use those
https://stackoverflow.com/questions/22008864/how-to-use-getaddrinfo-on-windows
wait ... it compiles ... thats all good ... it do notconnect. Windows code is https://github.com/Apollon77/libmbus/blob/build-windows/mbus/mbus-tcp.c#L80 ... and all compiles all good - it just not connects https://github.com/Apollon77/node-mbus/actions/runs/8440759330/job/23118438798#step:11:782
ooohhh .... what a fun ... digged around deep ... in the end it was just a wrong localjhost IPV6 adrress I used in the tests ("::" instead "::1" ... so it seems windows is very picky here and simply crashes the process ... I did not dfound any way to prevent that ... but in fact works :-) also on windows
:: is not localhost, that is like everything, similar to 0.0.0.0 in ipv4
I know ... it was a typo ... somehow was working in linux and macos tests :-)
so ... 2.2.0 of the lib is on the way to npm https://github.com/Apollon77/node-mbus/actions/runs/8473482950
Thank you for your support
@Apollon77 Seems npm publish got an error on publish: https://github.com/Apollon77/node-mbus/actions/runs/8473482950/job/23218106014#step:7:139
yes .... there is another one aftewrwards succesfull
so it's node-mbus@2.2.1 which should be out
Tested and it works. Cheers
Thank you very much!
Describe the bug
Connect to IPv6 M-Bus server is not possible. Which make problems with IPv6 only networks or places where already ISP can not give public IPv4 because was exhausted in 2012. Would be nice after 12 years able to use IPv6.
I can connect over netcat, so it is not network problem.
To Reproduce
Steps to reproduce the behavior:
Error: No connection possible to MBus Host
Expected behavior
Get data
Screenshots & Logfiles
Versions:
Additional context
Add any other context about the problem here.