Hi,

Understanding the security risk mentioned above, I'm still curious if it's possible to get this (telnetd) working on my SMCWAPS-G?

I checked via ftp using 'nobody', and there is a telnetd in /sbin, linked to /bin/busybox, but I still cannot ftp put the updated passwd file into /var/config/passwd ("cannot create file").

Thanks!

Jim

Hi,

My SMCWAPS-G is at SMC FW R4.00c2_0130, and I was thinking that maybe the reason that those files are not writable is because of that, so I tried to downgrade to FW 20060313_SMC_WAPS-G_R400b5v4.BIN (downloaded from SMC).  I tried this via the Web admin, but I get a "Unallowable firmware upgrade".

Why is that?  Can I not downgrade the firmware to b5v4 anymore?

Again, both the current c2_0130 and the b5v4 that I have were downloaded from SMC.

Thanks,
Jim

Hi schufti,

To answer your question, I guess that I was hoping to take the least risky approach, to "get my feet wet".

Having said that, I think I understand what you're saying, about the backdoor, but I've been reading through the wiki, plus this forum for about a week, and I'm a little confused, which makes me even more wary about doing something like this.  I suppose that you've been working with these devices for awhile, so you're comfortable with doing this stuff, but as a relative newbie to this, it's a little different ...

But, if that telnet procedure at the beginning of this thread isn't going to be possible, then I guess I'm willing to try, but, before I do that I'd like to confirm some things.

1) "Recovery Loader":  Going through a lot of reading, I think that, by "recovery loader", you're referring to the procedure here:

http://www.macsat.com/macsat/component/option,com_openwiki/Itemid,66/id,recovery_from_bad_flash/

i.e.,

a) Connect a WinXP machine directly to the SMCWAPS-G via either a crossover cable or via a switch
b) Set PC IP address to 192.168.123.xxx (e.g., 192.168.123.50)
c) Put the SMCWAPS-G into recovery mode by power off, press and hold both buttons, and then power on
d) On PC, run command: TFTP -i 192.168.123.254 PUT c:\filename.BIN

Is that correct?

2) From this link:

http://www.macsat.com/macsat/component/option,com_openwiki/Itemid,66/id,rebranding_the_fw/

I think it says that a "complete" firmware has 5 sections, with each section having something like:

xxxxxx00: 4c4c 4d5f 5255 5330 3031 0000 0000 857e LLM_RUS001.....~
xxxxxx10: 5175 6565 6e00 0000 0000 0000 11e1 6bc7 Queen.........k.

So, if I use a hex editor, and look through a .BIN and find 5 such strings, that means that the .BIN contains a "complete" firmware.

Is that correct?

3) Re. use of "recovery loader":  Is it correct that given either a "complete" (i.e., 5 sections) firmware or a "not complete" firmware .BIN, the recovery loader procedure works in most situations?  What I mean by "most situations" is that, unlike the web upgrade, which apparently checks checksums and matches branding, that if I do a recovery loader procedure, whatever I send via TFTP will get flashed to the SMCWAPS-G firmware, regardless of the branding info or bad checksum in the .BIN?

Part of the reason for this particular question is that you suggested "flash the c3 gui via rec. loader", and I was looking at "uc3gui.bin", and the beginning looks like:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  40 6D 21 74 72 26 64 00 00 00 00 00 00 00 EC 0C  @m!tr&d.......ì.
00000010  40 6D 21 74 72 26 64 00 00 00 00 00 8B EE 6B C7  @m!tr&d.....‹îkÇ
00000020  00 00 3B 00 00 00 04 00 10 00 3B 00 04 BA 02 00  ..;.......;..º..
00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000040  42 48 01 01 50 00 05 01 00 00 3B 00 0B 00 3D 27  BH..P.....;...='
00000050  40 4D 21 54 2E 00 00 00 00 00 00 00 00 00 00 00  @M!T............
00000060  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000070  60 00 00 00 1C 0C 00 00 B0 AD 02 00 80 B2 02 00  `.......°­..€²..
00000080  58 B5 02 00 48 B7 02 00 B4 B7 02 00 74 B8 02 00  Xµ..H·..´·..t¸..
00000090  B4 B8 02 00 0C B9 02 00 00 00 00 00 00 00 00 00  ´¸...¹..........
000000A0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000B0  7D 00 FF FF 61 70 2E 68 74 6D 00 FF FF FF FF FF  }.ÿÿap.htm.ÿÿÿÿÿ

i.e., it's not (what I call) a "complete" .BIN and it doesn't have the branding string.

So, I'm assuming that even though that is the case, I can use the recovery load procedure (using TFTP) to just "push" the above .BIN file and update the SMCWAPS-G flash.

4) This question is re. your suggestion:  I'm understanding that you're saying to use the recovery loader/TFTP to update the SMCWAPS-G firmware from "uc3gui.zip" from your repository.  From looking at the uc3gui.bin, it looks like this contains a bunch of HTML pages, and, I guess replaces just the web gui of the SMCWAPS-G. 

Is that correct?

Then you suggest "upgrade with the latest of my files", but I'm not sure which is "the latest of my files"?
Which file are you referring to, and are you talking about from Rapidshare or from "http://schufti.macsat.com"?

Also, I'm curious, with what you're suggesting, why the two separate .BIN files, rather than what I call a "complete" .BIN with the 5 sections in it?

5) Finally, if I do the uc3gui and the other upgrade, what kind of functionality is added vs. the SMC firmware?  I'm not asking for a detailed list , but, in general?  Also, will I "lose" any functionality vs. the original SMC firmware?


Sorry for all of the questions ..  As I mentioned to Ernst in the other thread, I am kind of a little worried about bricking my SMCWAPS-G, as I do use it, and they're getting harder to find...

Later, and thanks!!

Jim

Hi,

Out of curiousity, I re-tried the web GUI firmware downgrade, but this time from another PC that was connected to the same switch that the SMCWAPS-G is connected to (earlier, I have been doing it from a PC in another room - which is also connected physically, but going through my main router and then to a hub, and then, finally, the switch that the SMCWAPS-G is physically connected to).

Guess what?

Yep, this time, the downgrade worked.

After checking whether or not the /etc/passwd still had only read permissions (it did ), I reflashed the SMCWAPS-G to c2_0130, which again worked.

So, basically, I'm back to where I started, at SMC's 4.00c2_0130, but now I know that if I do a flash, I'm going to have to do it from that PC that's on the same physical switch as the SMCWAPS-G itself.

Having said that, I'm not 100% sure why doing it from my main PC didn't work.  I'm assuming that maybe it was because of some timing differences because of the number of routers/switches/hubs that it went through.

Whew !!

Jim

schufti,

I think I just did it (upgrade).  This is probably getting a lot off-topic, so I'll post a new thread with the details.

Thanks,
Jim

schufti,

Thanks for the answers!!

Jim