sonoff-hack
sonoff-hack copied to clipboard
Web Interface does not respond with 0.1.2 an fw 40620220309
GK-200MP2B sonoff-hack 0.1.2 Firmware:40620220309
I made a factory reset of the camera and copied the sonoff-hack 1.1.2 to the sd card.
- eWeLink makes a connection and works.
- the WEB Interface does not respond.
(With < 0.1.2 and an older fw it worked fine.)
Any suggestions how diagnose?
Which port are you using?
8080 Background: I had a working installation with an older firmware version, I think it was 25241245. Then the camera made an fw update (unfortunatelly I clicked the button) From that time on the web interface didn't respond anymore, but other functions (e.g. MQTT) remained working. Then I tried to setup from scratch, made a factory reset of the camera und useing sonoff-hack 0.1.2
With 0.1.0 I moved the web server to the standard 80. Try it.
- is pingable
- Response on Port 80: ERR_CONNECTION_REFUSED
- Port Scan (0-8100): 23 telnet 554 rtsp 8080 http-alt
Maybe you mantain the old config on port 8080. The port is open. It is strange that the web service is not working.
I think I have the same Sonoff FW version. I can get the web working, but it sometimes stops responding and needs a reboot. RTSP is working great, but PTZ is not working.
Nmap scan report for sonoff-5f23.local (xxx.xxx.x.xxx)
Host is up (0.075s latency).
Not shown: 996 closed tcp ports (conn-refused)
PORT STATE SERVICE
23/tcp open telnet
80/tcp open http
1000/tcp open cadlock
7103/tcp open unknown
No SSH, telnet seems to be open, but password is not working.
I will check it.
Hi, @roleoroleo first of all, thank you for this great project.
I had the same problem with my GK-200MP2B which was shipped with V5520.2053.0379build20220208 and later updated to V5520.2053.0402build20220712.
SSH and pure-ftpd are not starting. PTZ does not work (same as #93). Also some settings like ssh password do not work.
After checking I found out that the new firmware did not include libcrypt.so.0
, libhardware.so
nor libptz.so
.
/etc
is also no longer writable.
For the /etc
problem I will create a pull request.
As for the missing files, I am not sure yet how to deal with them. Right now I copied the files from a Ver24520191030 dump to sonoff-hack/lib
. We need to compile openssl for libcrypt.so.0
. For libptz.so
we need our own solution?
Could you share a dump of the flash? I need to analyze this version.
If it helps, I can share a backup dump via email (I don't want to post it here as I think the backup was after configuring the camera so there may be some personal info in it). My eWeLink app reports version 37620220117.
Also, could you share the command you use to mount the raw mtd images? I had wanted to poke around (since I can't get SSH) but couldn't figure out how to mount the images.
@roleoroleo Here are the dumps of the two version I have. Both are missing mtd5
I can provide it by request.
- V5520.2053.0379build20220208.tar.gz This dump was after starting sonoff-hack and using LAN only, should be free of personal information.
-
V5520.2053.0402build20220712.tar.gz
This was done after using the eWELink and configuring WiFi, so I did not include
mtd3
(If you need, please tell me).
@ConorIA
Also, could you share the command you use to mount the raw mtd images?
mount -o loop,ro mtdX.bin /mnt
Sorry but I'm not able to support this version, at the moment. There are too many differences in the file system.
Sorry but I'm not able to support this version, at the moment. There are too many differences in the file system.
@roleoroleo , please can you explain your problems with supporting this version. Is it lack of time?
Did you see my pull request? It will solve the issues with the different file system and should be still backward compatible (but I can't verify it due to lack of hardware).
For me, my cam works with the provided pull requests and IMHO the effort to maintaining those patches in this repro is less work than starting a new fork.
my cam works with the provided pull requests
~~Do you have PTZ working?~~
Nevermind, saw your additional PRs. Thanks for figuring it all out.
@roleoroleo , please can you explain your problems with supporting this version. Is it lack of time?
At the moment it's lack of device :) I think it's not only a fw update but a different hw (but I'm not sure because I didn't try to force the new version on my old cam). For sure, the app doesn't show me a software update.
For me, my cam works with the provided pull requests and IMHO the effort to maintaining those patches in this repro is less work than starting a new fork.
I could try.
Hi @roleoroleo I built a version that merges @puuu's three PRs. Attaching here in case you want to throw it on an SD card and give it a try on your older hardware.
At the moment it's lack of device :) I think it's not only a fw update but a different hw (but I'm not sure because I didn't try to force the new version on my old cam). For sure, the app doesn't show me a software update.
I see. I am also expecting different hardware, so I haven't tried downgrading the kernel.
For the time being, I can check the firmware on my hardware. Maybe @ConorIA can test it too?
If we should check something special, please tell.
@puuu @ConorIA I released 0.1.3 Could you please check if it works properly on your hardware. Thank you.
OTA update worked fine.
I have working HTTPD, PTZ, RTSP, and SSH. No cloud is enabled. Have not tried OMVIP (disabled), but assuming it is all working.
I think we've got full functionality! Thanks so much to both @puuu and @roleoroleo.
@roleoroleo thank you for integrating my pull request and creating a new release.
I installed 0.1.3 freshly and it is working as expected since 3 days.
Unfortunately, I have issues with rtsp (already before installing 0.1.3):
- First (after a restart) rtsp is working fine. Connecting from Home Assistant and VLC works without problems. VLC also provides audio.
- After some time (about 8 to 12 hours) when I connect to rtsp again, Home Assistant is working, but VLC shows the current frame and a rotating VLC logo. I expect the audio channel is broken, sometimes VLC works but then without audio.
- Restarting of
avencode
(killall avencode
and wait until wd_rtsp.sh start it again) will bring back rtsp alive, with VLC audio, but then the time in the video shows a wrong timezone.
@ConorIA can you reproduce the rtsp problem?
@roleoroleo do you have any idea what the problem could be. I disabled the cloud service. Enabling the swap file does not help.
Can you reproduce the timezone problem on your device? I tried to set the TZ
variable in wd_rtsp.sh
but it did not help.
Can you reproduce the timezone problem on your device? I tried to set the
TZ
variable inwd_rtsp.sh
but it did not help.
Maybe avencode should be executed without TZ variable. You could try to unset the variable in wd_rtsp.sh before starting avencode.
Maybe avencode should be executed without TZ variable. You could try to unset the variable in wd_rtsp.sh before starting avencode.
Thank you, this is the trick. Now the time is also after killall avencode
correct. Is this also ok/required for older firmware?
BTW, why wd_rtsp.sh
needs MODEL_SUFFIX
?
Furthermore, TZ
in system.sh
do not work. The cgi-bin scripts only write and read to/from ipcsys.db
not system.conf
.
So how about removing the TZ definition in system.sh
?
I don't remember why I added TZ. I will investigate.
@roleoroleo as for my test on my model, crontab also only works correctly if TZ
is not set in system.sh
. Otherwise the task are executed on a different timezone.
How is the behavior on other models?
I studied in deep the problem because I didn't remember anything.
TIMEZONE parameter in system.conf is a typo (it's no longer used). When you save the timezone from the web page, the script writes it directly into the sonoff db (as if you were doing it from the app). So, export TZ in system.conf must be removed. Try to remove the export and check if it works.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.