Talk:Enabling Login
Please provide feedback of your upgrade and patch experiences here .....
Early problems, Autumn 2007
First patch attempt Followed the readme docs - obtained all the necessary files, got the 5 magic numbers! I'm utterly confused about what to do with Cygwin (which I've installed). Need some detailed advice on this. Thanks.
Trumpton Cygwin provides some essential libraries that are used by the patchserver. Once installed, you should be able to open up a command shell (Start/Run 'cmd'), change directory to where you unpacked patchserv.exe (using cd), and run 'patchserv test.tar.bz2
PeterPan: I just install the cygwin envirement, run the patchserver und transfers the 'test.tar.bz2' Test patchfile to my IPdio. That seems to work. But I have not heart enough, to transfer the real patchfile 'Devel-00-01b-login_http.tar.bz2' because my IPdio is only 2 days old. I am not a Linux expert (I am a Windows developer) So what about the install-me script? Who will run it?
Unknown: I installed cygwin - wow! that ate up my disk space. Can you tell me what I can safely delete from Cygwin (if anything) and still get patchserver to run?
Can you give explicit telnet commands to enter to login and run the savespace. A definitive example would be useful (eg. open , etc). What is the server name to open? for example. Or is it the radio's IP address?
In your warning section, you mention you've trialed on a few radios. Can you list the radios which you've successfully tried? This may either encourage or scare the faint-hearted!
PeterPan: I think you only need the cygwin1.dll. To connect to the radio via telnet. You must start telnet in a cmd shell. Than type open and then type the IP-Address of your radio. For example open 192.168.0.10 or you type in telnet 192.168.0.10
Trumpton Peterpan - When you do an install, the main radio application launches a script, which moves the radio from runlevel 2 to runlevel 3 (effectively shutting down the radio application). The script then downloads the patchfile, unpacks it to /tmp/something, and then looks for /tmp/something/install-me scripts, which it automatically runs as root.
The login_http patchfile install-me script does a disk check, copies a new busybox application (busybox.new) to /bin, and creates the links for telnetd and httpd. It also copies the init scripts for the two servers, and finally creates some dummy webserver files. the one thing it does not do is tamper with the original busybox program - we provide a script called 'savespace' which will remove the original program, rename the new one, and correct all of the links, but at present, this is left for you to run once you have logged in. So you see, we have taken the 'chicken' route in patching the radio, and have not deleted any existing files.
Unknown - I think Peterpan is right, all you need is the cygwin1.dll. I would have bundled it with the application, however, the cygwin Ts&Cs forbid it. The Savespace script will save 600Kb of diskspace on your radio, nothing on your PC.
It is our intention that in the end, this is the only program you will have to install this way. Future patches will be done using the installed webserver. Presently, however, the webserver is only a stub, so the early takers will probably have to re-patch in order to benifit from the full features.
This method has been run by me on a Logik IR100 and a Logic IRMA1. There are many people who have patched their radios, but have done it manually (without the advantage of the patchserver); and most of them have installed an ssh shell, which takes a little more disk space, does not have the advantage of the additional webserver, and is slightly larger when running in memory.
PeterPan: thank you for your explanation Trumpton. I just did the patch and get telnet and http connection to my IPdio. Great! I got the following error message when I run the savespace script.
mount: mounting /dev/root on / failed: Device or resource busy
What does that mean? If I check with mount, it seems that all filesystem has rw access. Is that correct?
Trumpton This is not a problem! If you type 'ls /bin/busybox*' you should see a single busybox program (i.e. no busybox.new), which shows that the script ran OK. You just need to type 'sync;telinit 6' which will flush disk buffers, and force the radio to reset (may take 30 seconds for the watchdog to actually do the reset).
PeterPan: My Radio is dead :-( After I replugged it to the power, the device did not boot anymore. I send it back to my dealer. Do you have any idea, about the cause?
Trumpton The only thing the upgrade could have done to affect the radio this way is not complete the busybox copy properly. As you managed to use 'ls', you demonstrated that the install worked OK. I presume the radio had also rebooted a few times OK before this happened? I'm afraid I'm a little stumped. I've had my radio non-booting several times, but that's been because I've had it in about 1000 pieces too often, and the connectors don't fit quite as well as they used to. I've been through this upgrade method at least half a dozen times during testing.
Can you explain where the savespace procedure comes into the patching procedure? There's NO mention of it in the docs. Also does the webserver stay loaded on the radio after patching and when the radio is rebooted and reset to use DCHP?
Trumpton savespace is used after the install, but it's pretty advanced, and quite dangerous, so the release we are working on will not have it (so it's nothing to worry about). Our intention is to provide a patchfile to uninstall all sharpfin mods instead. The patchserver is for patching only, and once you re-configure the radio back to its original settings (probably DHCP), the webserver and telnet server will stay running after reboot. The webserver files live on the debug partition (/mnt/debug), so you can modify files without having to tamper with the main operating system disk. The telnet server and webserver both use the same executable, so once one is loaded, there is little memory impact on having the other also!
So where is the patch file?
samjam My Tevion player doesn't show any of the LCD text messages for the test patch file, it just restarts the network after a while,
Please enter the IP address of your real DNS server: 192.168.1.254 Setting nameserver to: 192.168.1.254 Patch file is sharpfin-test.patch patchserver: Running webserver on port 80 patchserver: running DNS Server on port 53 webserver: waiting for connections ... dnssever: waiting for connections ... dnsserver: 192.168.1.249: forged lookup www.reciva.com ... OK webserver: 192.168.1.249: request for /cgi-local//service-pack.pl?serial=00029fbc&sp=v257-a-297-a-027&hw=926&sv=03&check=1 ... OK dnsserver: 192.168.1.249: forged lookup www.reciva.com ... OK dnsserver: 192.168.1.249: forged lookup www.reciva.com ... OK dnsserver: 192.168.1.249: forged lookup www.reciva.com ... OK dnsserver: 192.168.1.249: forged lookup www.reciva.com ... OK dnsserver: 192.168.1.249: forged lookup www.reciva.com ... OK webserver: 192.168.1.249: request for /cgi-local//service-pack.pl?serial=00029fbc&sp=257-a-297-a-027&hw=926&sv=03&check=0&favoured_portal=reciva://dragon.reciva.com:6000 ... OK dnsserver: 192.168.1.249: forged lookup www.reciva.com ... OK webserver: 192.168.1.249: request for /reciva-upgrade.tar.bz2 ... OK
I don't know if it worked or not.
The link to the real patch file on the enabling_login page is not there,
Trumpton samjam, I am a little concerned that the 'lcdprint' program we have produced is not working with your Tevion. It could be that the hardware is sufficiently different that it is not compatible with our libreciva hardware library (which is based on the 255-c-xxx releases). Could you try again with the latest version of the patchserver to see if there is any difference.
patchfiles are just .tar.bz2 files which contain an install-me script. The sharpfin-base patchfile installs three ipkg files (sharpfin-base, sharpfin-www and sharpfin-telnetd) These do not overwrite any existing programs, but essentially install /bin/sharpfin /bin/login /usr/sbin/httpd /usr/sbin/telnetd /etc/rc2.d/S10telnetd /etc/rc2.d/S15httpd and various webpages and scripts. These files should not collide with any of the existing files on your radio
When you say restarts the network, does your radio reboot?
samjam: It is possible that the problem lies with the lcdprint program's contrast adjustment. The radios we have access to do not have a contrast capability, so we have been unable to test the contrast code. The lcdprint tries to set the contrast to 50%. Could you drop me an email at trumpton(*)sharpfin.zevv.nl, and I'll send you a different test.patch file to try, which does not adjust the contrast at all
samjam: Well... I patched it with the real patch and it worked - I can now login THANKYOU.... but I never did get anything on the LCD.
I've emailed you so I can try to debug the lcd with you. Maybe now I will get NTP to work so I don't have to set the clock every time it turns on.
(Funny, because it when patchserver is running I see it resolve ntp.reciva.com)
DNS lookup failure - fix: use a path without spaces for the files on XP
Nigelcliffe; Unfortunately stuck at first hurdle; the patchserver runs on my computer (well two of them), but though the radio connects, the patchserver doesn't then connect to the DNS to perform the lookup. Thus those lookups all fail, and the radio reports a DNS problem. Any clues ? ISP is Demon and a static IP address if that's the issue.
Trumpton - it is possible that a firewall is getting in the way. Have you tried running the patchserver, and then typing 'nslookup www.microsoft.com 127.0.0.1' at a cmd prompt on the local machine? This will force a DNS lookup to occur without actually doing a patch. Also, what platform are you running the patchserver on - Vista for me hid the firewall query box under all of the other windows, and never asked me again!
Nigelcliffe - Here are the outputs from one of my machines. Same if I turn off the firewall (Windows XP one). It would appear that my patchserver isn't getting the DNS from the DNS server. But a direct query to the DNS (ie. not via the patchserver) address gets a reply instantly.
Trumpton: Bingo! We've seen this one before. The how-to-video was done using Vista, and there are no spaces in the path to the desktop. XP, however installs the program in "Documents and Settings". The shell that launches the real patchserver (command line version) passes the path to the file and the DNS server as arguments, and the spaces muck things up. If you install the patchserver in a directory that does not contain any spaces in the path (e.g. c:\patchserver) things should start to work.
Nigelcliffe; Many thanks Trumpton. Have moved patchserver and patchfiles to c:
igel and it the DNS lookup test works. I'll try the radio later when I have more time. Once you mentioned it, I recall seeing that detail in the videos. But I watched the videos a few weeks ago and have been working from the PDF notes. Suggestion, if not too much trouble, is to put a note about this one in the PDF as well ? I've changed the section title to include the fix !
Nigelcliffe Another little hint; Windows XP Firewall can defeat the patchserver. Whilst it looks OK on the surface, the "allow" option was checked, and the local loop test works, a remote machine (radio) fails to connect. My solution was to switch it off for the duration of the patching exercise.
musojon74 Interestingly, on this subject, I've been unable to make the dns lookup work from patchserver and am on vista64ultimate, patchserver in c:\radiopatch All stuff set up correctly, but just get endless time outs from portal1, the first one. then the radio says "dns servers invalid". Have checked repeatedly, and turned off windows defender, windows firewall, avast, even (briefly) the bt home hub firewall. no luck whatever! Radio is a Bush tr2015wifi. nslookup confirms I am using the right nameserver ip. I have no clue how to proceed! The only thing I can think - I might try the other computer with Linux on it.
Trumpton With the patchserver running, open a command prompt, and type:
nslookup www.microsoft.com 127.0.0.1
You should see some traffic in the patchserver window. I've never dealt with 64-bit Windows - it is possible that the API for the DNS is different, but I doubt it.
musojon74 OK thanks, I've just done as you suggest - we get more timeouts, firstly on 1.0.0.127.in-addr.arpa, then 2 www.microsoft.com.home, then 2 www.microsoft.com. Bizarre. I'll maybe research into the APIs tomorrow. Obviously the nslookup window times out too.
Oops
Manksman Suggestion - "We recommend installing any previous third party patches" should read "Uninstalling"
Trumpton Thanks MM. This article is the only write-protected page, as we'd hate someone to upload a trojan, and others download it thinking it's a tested release.
Config.txt
Nigelcliffe I created a new Wiki page for detailing information on the Config.txt File, separating it from its little bit on the bottom of the Changing Firmware page. Could you add suitable links to the Enabling Login page please ?
trumpton Done! - I've unprotected the page also. The only reason it was protected was that it contained the downloads, and I didn't want people uploading viruses etc.. instead of the download apps. Now downloads are on the releases page, that is protected instead. - thanks for your help, we need more people like you!
Network Error. DNS servers invalid.
christopherpm - Running Vista Ultimate.
My PC details are:-
IP - 192.168.1.98 SM - 255.255.255.0 GW - 192.168.1.254 NS - 192.168.1.254
Radio:-
192.168.1.64
Installed Cygwin Run patchserver - this starts ok (nothing else using ports 80 or 53 on my computer). On radio, set DHCP to No, IP to 192.168.1.64, SM to 255.255.255.0, GW to 192.168.1.254, DNS1 to 192.168.1.98
I don't set DNS 2.
The radio initially reads "Connecting to network" but then reads "Network Error. DNS servers invalid"
I have disabled the firewall on he PC but to no avail.
Any ideas please?
trumpton - the addresses you have used look fine. Can you confirm that you type '192.168.1.254' into 'patchserver' when prompted for the DNS server?
Something else you can try is: with the patchserver running, open a command window up on the same PC, and type 'nslookup www.google.com 127.0.0.1', 'nslookup www.reciva.com 127.0.0.1', then 'nslookup www.google.com 192.168.1.98'.
Steve
christopherpm - Yes I have entered 192.168.1.254 into patchserver.
I did try using nslookup locally to test that DNS was running ok, and it is.
I wonder if this problem is down to running Vista Ultimate instead of Vista Home (which I do not have access to).
I'm using Vista Home Premium (I think it is called), and it does have a firewall, but popped up a box asking me if was OK to run the patchserver. I'm definately confused - if you have a second PC on the network, you could try nslookuping from that one - that would definately eliminate the radio as the cause!
No web server on Roberts WM201
I've just patched the above radio and rebooted. I can access the device via telnet but not via the web interface. I've logged on and there appears to be nothing in /opt!
$ mount rootfs on / type rootfs (rw) /dev/root on / type jffs2 (ro) none on /dev type devfs (rw) proc on /proc type proc (rw) tmpfs on /mnt/ramfs type tmpfs (rw) /dev/mtdblock/3 on /mnt/config type jffs2 (rw) /dev/mtdblock/4 on /mnt/debug type jffs2 (rw) none on /proc/bus/usb type usbdevfs (rw) $ ls -l / drwxr-xr-x 2 0 0 0 Jan 1 00:04 bin drwxr-xr-x 2 0 0 0 Jun 20 2007 boot drwxr-xr-x 1 0 0 0 Jan 1 00:00 dev drwxr-xr-x 18 0 0 0 Jan 12 2008 etc drwxrwxr-x 3 0 0 0 Jun 20 2007 lib -rwxr-x--- 1 0 0 550 Oct 27 2006 linuxrc drwxr-xr-x 6 0 0 0 Jan 12 2008 mnt lrwxrwxrwx 1 0 0 9 Jan 1 00:04 opt -> mnt/debug dr-xr-xr-x 38 0 0 0 Jan 1 00:00 proc drwxr-xr-x 5 0 0 0 May 23 2007 root drwxrwxr-x 2 0 0 0 Jun 20 2007 sbin lrwxrwxrwx 1 0 0 14 Jun 20 2007 tmp -> /mnt/ramfs/tmp drwxr-xr-x 7 0 0 0 Jan 12 2008 usr lrwxrwxrwx 1 0 0 14 Jun 20 2007 var -> /mnt/ramfs/var
Any more info I can provide? Dicko 23:50, 16 March 2008 (CET)
Trumpton - you should have some files in /mnt/debug (which is where the opt softlink points). Can you do the following:
- ls -la /mnt/debug
- ipkg info (and pull out the sharpfin entries)
Thanks, Steve
Nope, /mnt/debug is empty!
$ ls -la /mnt/debug drwxr-xr-x 3 0 0 0 Jan 1 00:00 . drwxr-xr-x 6 0 0 0 Jan 12 2008 ..
Package: sharpfin-base Version: 0.1 Depends: libc6, reciva-kernel Provides: httpd, login, telnetd Status: install user installed Architecture: arm Installed-Time: 267 Package: sharpfin-httpd Version: 0.1 Depends: sharpfin-base Provides: httpd_init Status: install user installed Architecture: arm Installed-Time: 269 Package: sharpfin-telnetd Version: 0.1 Depends: sharpfin-base Provides: admin_account user_account telnetd_initscript Status: install user installed Architecture: arm Installed-Time: 268 Package: sharpfin-www Version: 0.6 Depends: sharpfin-base sharpfin-httpd Provides: webserver_files Status: install user installed Architecture: arm Installed-Time: 271
Dicko: Are the packages retained somewhere on the device so that I can retry the install manually? I also notice that the system time on my device is some time in 1970. Could this cause any problems? How often does it attempt to sync the time?
Dicko again: I just created a file on /mnt/debug and then rebooted the radio by powering it down... The file disappeared! So it looks like contents of /dev/mtdblock/4 does not survive a powerdown. Is this different to other platforms?
Trumpton This is strange. All of the versions I have seen do not wipe the /mnt/debug partition. It looks like there is something in the startup script to wipe this directory. What version of firmware have you got installed?
regarding the clock, It seems to take a while to sync. The clock in the radio application does not seem to sync to the OS clock either. I've seen timestamps in 1970 many times before, and I'm sure it's not a problem.
When the radio boots, it runs scripts in the /etc directory, working out which scripts to run from /etc/inittab.
By default, it runs the /etc/init.d/rcS script, It then goes t hrough running anything tagged as runlevel 2 (the default) - that is anything with xx:2:xxxxx When it runs "/etc/init.d/rc 2", that script goes through the /etc/rc2.d directory running scripts in numerical order.
I'm guessing it is related to the following lines in /etc/init.d/rcS script:
if [ `mount|grep -c /mnt/debug` -eq 0 ] ; then DEBUG_PARTITION=`grep /mnt/debug /etc/fstab|cut -f1 -d' '|sed -e s/block//` echo "Debug partition didn't get mounted. Erasing and mounting it..." flash_eraseall $DEBUG_PARTITION mount /mnt/debug fi
In my /etc/fstab, I see the following
# <device> <mountpoint> <filesystemtype> <options> <dump> <fsckorder> /dev/root / jffs2 defaults 0 0 tmpfs /mnt/ramfs tmpfs noauto 0 0 proc /proc proc defaults 0 0 devpts /dev/pts devpts mode=0622 0 0 /dev/mtdblock/3 /mnt/config jffs2 defaults 0 0 /dev/mtdblock/4 /mnt/debug jffs2 defaults 0 0 /dev/mtdblock/5 /mnt/ramfs/var/data jffs2 noauto 0 0
What does yours look like?
Dicko: My fstab is exactly the same and I think you are right about /etc/init.d/rcS. Is it safe for me to comment out the code in rcS and then mount /mnt/debug manually to see the error? More tests, if I unmount /mnt/debug and then issue the same mount -a command as is in rcS, it does NOT mount /mnt/debug! If I do a standard mount -a without any exclusions, it does mount /mnt/debug... Very strange.
Firmware version is V257-a-297-a-007 BTW
Trumpton - if you make any mistake editing rcS, it is possible that you may brick your radio, so a little care is probably in order. I suspect that commenting out the flash_eraseall line in the debug section will make it work, however, I believe that this is fixing the symptom, and not the cause.
I suggest we get some more info on your "umount" and "mount -a" command, perhaps looking in the logs. When I umount and "mount -a", then type dmesg, I get:
jffs2_get_inode_nodes(): Data CRC failed on node at 0x000e99a4: Read 0x8801b79f, calculated 0x7ac793ba jffs2_get_inode_nodes(): Data CRC failed on node at 0x000e8ce4: Read 0x8801b79f, calculated 0x813901a6 jffs2_get_inode_nodes(): Data CRC failed on node at 0x000e8350: Read 0x8801b79f, calculated 0x7b9b7f63 jffs2_get_inode_nodes(): Data CRC failed on node at 0x0008869c: Read 0xebca56ba, calculated 0x2d4b215c
Which suggests that my partition has some corruptions on it, yet it is still managing to mount - yours may be a little more catastrophic. I've umounted, flash_erased and re-mounted and I no longer get the errors. What outputs do you get?
Dicko: None of my (u)mounts produced anything in dmesg and I can mount and unmount /mnt/debug without any problems from the command line. What I meant previously was that if I dismounted /mnt/debug and then issued the "mount -a" command, it worked. However, if I used "mount -avt nonfs,noproc,nosmbfs,notmpfs" as in /etc/init.d/rcS it didn't. So I was wondering if maybe there's a bug in BusyBox. There seem to be a lot of fixes to the mount command, however, their bug tracker site is down ATM.
Maybe just a change to the initial mount -a command is safest?
Later... Looking at the Busybox code in mount.c, I don't think the installed version supports -t nonfs,noproc,nosmbfs,notmpfs but why does this only cause a problem on my device? In fact, the correct syntax seems to be -t nonfs,proc etc. but that wouldn't work with this version of BB either It's version 1.5.1 BTW. Is that the same version as other devices?
Later still... I was wondering why I wasn't seeing the same problem with /mnt/config so I looked again at the code in /etc/init.d/rcS and it looks like the step that produces CONFIG_PARTITION doesn't work! Otherwise that would be getting nuked too... Execution the comands gives:
# grep /mnt/config /etc/fstab|cut -f1 -d' '|sed -e s/block// /dev/mtd/3 /mnt/config jffs2 defaults # grep /mnt/debug /etc/fstab|cut -f1 -d' '|sed -e s/block// /dev/mtd/4
So CONFIG_PARTITION ends up as "/dev/mtd/3 /mnt/config jffs2 defaults" which presumably causes flash_eraseall to barf and then the next mount command does the actual mounting of /mnt/config that actually works! Hexdump reveals that there's a tab between /dev/mtdblock/3 and /mnt/config and a space between /dev/mtdblock/4 and /mnt/debug in /etc/fstab.
I have reported this via the Reciva forum.
Trumpton Ah, I've found a bit of a difference ... My /etc/init.d/rcS script is as follows:
#! /bin/sh export PATH=/sbin:/bin:/usr/sbin:/usr/bin hostname -F /etc/hostname mount -a # Check that debug and config partitions got mounted correctly, otherwise # erase them and mount again if [ `mount|grep -c /mnt/debug` -eq 0 ] ; then DEBUG_PARTITION=`grep /mnt/debug /etc/fstab|cut -f1 -d' '|sed -e s/block//` echo "Debug partition didn't get mounted. Erasing and mounting it..." flash_eraseall $DEBUG_PARTITION mount /mnt/debug fi if [ `mount|grep -c /mnt/config` -eq 0 ] ; then CONFIG_PARTITION=`grep /mnt/config /etc/fstab|cut -f1 -d' '|sed -e s/block//` echo "Config partition didn't get mounted. Erasing and mounting it..." flash_eraseall $CONFIG_PARTITION mount /mnt/config fi
Note that the mount is just mount -a !! so the reason I would not have the same problem is due to having a different firmware ! I'm running 257-a-421-a-091 on my IRMA1.
My fstab does not have the same tab / spaces as you, however, the entries do have a combination of tabs and spaces, so I don't think that is an issue.
Dicko: I don't really understand the firmware numbering system. Which is the newer? I tried doing an "upgrade firmware" before I installed the sharpfin patches but it said my radio was up to date.
Assuming your firmware is newer, it would appear that they have removed the -t options from the mount -a and also removed the tab between the first two fields in /etc/fstab. So this should mean that it's safe for me to do the same...
Not done this before but I guess I need to remount / as read/write, make the changes to the two files, remount / read only then reboot and hold my breath! I guess I can do a test mount -a to confirm that still works before the reboot.
BTW Which version of Busybox is installed on your device?
Am I right in thinking that it's fine to just reinstall the sharpfin patches again without uninstalled the previous attempt?
Trumpton
421-a-091 is the latest release. You can download this once you get the webserver going. If you edit the file after mounting the disk r/w, run the script manually with ./rcS before rebooting! Reinstalling sharpfin won't end up with 2 copies. not sure if 'ipkg' will actually install tho, as it thinks the files are already there! Give it a go! Busybox is "BusyBox v1.5.1 (2007-07-11 16:58:22 BST)" but be careful ... different releases have different functions compiled! I have:
[, [[, ar, ash, awk, basename, bunzip2, bzcat, cat, chmod,
chroot, chvt, clear, cmp, cp, cut, date, dd, deallocvt,
df, dirname, dmesg, du, echo, egrep, env, expr, false,
fgrep, find, free, fuser, grep, gunzip, gzip, halt, head,
hexdump, hostname, id, ifconfig, insmod, ip, kill, killall,
klogd, ln, loadkmap, logger, logread, losetup, ls, lsmod,
md5sum, mdev, mkdir, mkfifo, mknod, mkswap, modprobe,
more, mount, mv, nc, netstat, nslookup, od, openvt, ping,
ping6, pivot_root, poweroff, printf, ps, pwd, reboot,
reset, rm, rmdir, rmmod, route, run-parts, sed, sh, sleep,
sort, stty, swapoff, swapon, sync, syslogd, tail, tar,
tee, test, time, top, touch, tr, true, tty, udhcpc, umount,
uname, uniq, uptime, vi, wc, wget, which, who, whoami,
xargs, yes, zcat, zcip
Dicko: The deed is done. I edited /etc/init.d/rcS & /etc/fstab and rebooted and /mnt/debug didn't get zapped. Reinstalled the Sharpfin package without issue and I now have a web interface in addition to telnet.
With Firmware (Beta) v257-a-865-a-??? it is not more possibel to install Sharpfin Patch-Files. For exempale the Sharpfin Test-Patch.
When you check for a Firmware Update - the radio reports Network Error.
Has anybody loocked with a TCP-Sniffer, what was changed in this Beta.
Having acess to telnet and scp would be fine to edit config-files.
Firmware (Beta) v257-a-865-a-??? installing Sharpfin
With Firmware (Beta) v257-a-865-a-??? it is not more possible to install Sharpfin Patch-Files. For exempale the Sharpfin Test-Patch.
When you check for a Firmware Update - the radio reports Network Error.
Has anybody loocked with a TCP-Sniffer, what was changed in this Beta.
Having acess to telnet and scp would be fine to edit config-files.
---
Think there are some changes necessary in the patchserver when answering the upgrade-prozess.
Today i did a Wireshark WLAN-protocol whit my fritz box when upgrading "IPdio mini pro" to the newest firmware.
If anyone of the patchserver programming team wants this protocol i can sent it. Please contact me.
kd