Hi!
I’ve been using the addon “Fritzbox Callmonitor” for a long time, however, it has stopped working on OSMC while it still works as expected on other platforms, e.g. Kodi on an Android tablet. I wonder whether this may be caused by some firewall or network setting on OSMC which I’m not aware of.
The addon is provided in the German kodinerds.net repo (which doesn’t host illegal content but which is very useful for German speaking users as it offers addons for German/Austrian/Swiss TV stations and other services mostly relevant in this market - just as Fritzbox routers). It monitors port 1012 of Fritzbox routers where incoming VoIP calls are signalled, checks the caller’s number in the Fritzbox’s phonebook, displays a notification in Kodi and reduces the playback volume and/or pauses playback if/when the phone is picked up. Very useful!
But while the addon works as expected on other platforms, I can’t get it to work any more on neither my Vero4K nor on a Raspi3 running OSMC which makes me think OSMC is the culprit.
I’ve already contacted the developer over at kodinerds.net, but they haven’t been able to help yet.
Is there anything in OSMC that might prevent an addon from opening/keeping open a connection on port 1012?
No firewall by default on OSMC
First step enable Debug logging, upload logs and share URL.
Second you could install tcpdump on OSMC and check if the addon is actually connecting to port 1012 on the fritzbox.
Same version of Kodi?
Is that system also a IPv4 or IPv6 system?
It’s Kodi 20.2 in each case, everything in my LAN is IPv4.
The Fritzbox log shows that Kodi successfully connects to the Fritzbox. I still need to enable debug logging on my OSMC devices, but here’s a short excerpt from kodi.log with some relevant lines (“grep service.fritzbox.callmonitor -i kodi.log”). After the last line, a loop of connected to port 1012, timeout and errors occurs. So the initial connection is made, but it can’t be kept open. The timeout takes five seconds (instead of one) because the developer suggested this change to the addon’s default.py (cf. the link to kodinerds.net above).
2024-01-06 09:07:14.637 T:2809 info : CAddonMgr::FindAddons: service.fritzbox.callmonitor v3.0.10+matrix installed
2024-01-06 09:07:32.853 T:2958 info : [service.fritzbox.callmonitor] Settings loaded
2024-01-06 09:07:32.879 T:2958 info : [service.fritzbox.callmonitor] Connected, listen to 192.168.2.1 on port 1012
2024-01-06 09:07:32.879 T:2958 info : [service.fritzbox.callmonitor] Looking for all phonebook modules in /home/osmc/.kodi/addons/service.fritzbox.callmonitor/resources/lib/PhoneBooks
2024-01-06 09:07:32.892 T:2958 info : [service.fritzbox.callmonitor] Found module file, import resources.lib.PhoneBooks.PytzBox
2024-01-06 09:07:46.464 T:2958 info : [service.fritzbox.callmonitor] Yield phonebook module PytzBox
2024-01-06 09:07:46.464 T:2958 info : [service.fritzbox.callmonitor] Found module file, import resources.lib.PhoneBooks.AppleCloud
2024-01-06 09:07:49.005 T:2958 info : [service.fritzbox.callmonitor] Yield phonebook module AppleCloud
2024-01-06 09:07:50.653 T:2958 info : [service.fritzbox.callmonitor] 120 entries from 192.168.2.1 loaded, 0 images cached
2024-01-06 09:07:55.670 T:2958 error : [service.fritzbox.callmonitor] Connection error, communication failure or other exception occured
2024-01-06 09:07:55.670 T:2958 error : [service.fritzbox.callmonitor] At line 354: timeout
2024-01-06 09:07:55.674 T:2958 error : [service.fritzbox.callmonitor] (‘timed out’,)
Then I guess tcpdump -n -i any host 192.168.2.1 might give some idea if a packet comes back.
Further testing:
a) I’ve installed the addon on my Odroid-C1 running a slightly older LibreElec fork - it works as expected.
b) On my Vero4K (aka 192.168.2.28) I ran “sudo tcpdump -n -i any host 192.168.2.1” - this is the output when I run the command and then call my landline phone with my mobile. I don’t see anything problematic, but I might be wrong.
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]… for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
11:51:17.922798 eth0 In IP 192.168.2.1.1012 > 192.168.2.28.57284: Flags [P.], seq 3970716507:3970716560, ack 126103038, win 453, options [nop,nop,TS val 773691221 ecr 770397], length 53
11:51:17.922909 eth0 Out IP 192.168.2.28.57284 > 192.168.2.1.1012: Flags [.], ack 53, win 229, options [nop,nop,TS val 776504 ecr 773691221], length 0
11:51:22.360226 eth0 Out IP 192.168.2.28.57284 > 192.168.2.1.1012: Flags [R.], seq 1, ack 53, win 229, options [nop,nop,TS val 776948 ecr 773691221], length 0
11:51:22.360505 eth0 Out IP 192.168.2.28.57290 > 192.168.2.1.1012: Flags [S], seq 1921093026, win 29200, options [mss 1460,sackOK,TS val 776948 ecr 0,nop,wscale 7], length 0
11:51:22.361410 eth0 In IP 192.168.2.1.1012 > 192.168.2.28.57290: Flags [S.], seq 1596203754, ack 1921093027, win 28960, options [mss 1460,sackOK,TS val 773692331 ecr 776948,nop,wscale 6], length 0
11:51:22.361511 eth0 Out IP 192.168.2.28.57290 > 192.168.2.1.1012: Flags [.], ack 1, win 229, options [nop,nop,TS val 776948 ecr 773692331], length 0
11:51:26.770461 eth0 In IP 192.168.2.1.1012 > 192.168.2.28.57290: Flags [P.], seq 1:36, ack 1, win 453, options [nop,nop,TS val 773693433 ecr 776948], length 35
11:51:26.770580 eth0 Out IP 192.168.2.28.57290 > 192.168.2.1.1012: Flags [.], ack 36, win 229, options [nop,nop,TS val 777389 ecr 773693433], length 0
8 packets captured
8 packets received by filter
0 packets dropped by kernel
Well you would need to capture the timeout topic. So in one terminal have the tcpdump running and in the other one run sudo systemctl restart mediacenter
Then compare timestamp with the Kodi.log