Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[asbokid]

Some more testing was performed last night.

The two methods of held "Reset" were used at device power up. ("Paper-clip in hole" method and "Finger on button" method.)

All five sockets that can take an RJ-45 plug were checked. The following nmap command line was thus executed ten times --

Code: [Select]

nmap -T4 -Vs -Pn -p0-65535 192.168.1.1

Absolutely nothing was found. 

Thanks b*cat.  Sorry for time waste 

Now my question. How certain are we that 192.168.1.1 would be the correct IP address? 

Hmm.. It seemed certain. But then they said that about L'pool winning the league 

The 'board IP address' is definitely listed as 192.168.1.1 in the CFE config section of the f/w of the HH3.0b.

Back to the head scratching - (thinking aid rather than relief of nits, for once) 

cheers, a

[burakkucat]

Nits? Do you have a louse infestation?    I wear a flea-collar and find that keeps the nasties at bay! 

I am quite convinced of the IP address, having now seen your evidence. What was bothering me was the analogy with the Huawei HG612. The IP address used for the GUI to re-flash its firmware is the same IP address as its normal user GUI, once unlocked. I was pondering if the "re-flash the firmware" GUI for the HH3.0B is identical to its normal user GUI -- that is 192.168.1.254   

[Howlingwolf]

I was pondering if the "re-flash the firmware" GUI for the HH3.0B is identical to its normal user GUI -- that is 192.168.1.254   

I tried that while I was fiddling about and got nothing until the normal web interface came up.

I looked through the bootloader block myself after I gave up but couldn't see anything else which might be a likely candidate.

[asbokid]

I am quite convinced of the IP address, having now seen your evidence. What was bothering me was the analogy with the Huawei HG612. The IP address used for the GUI to re-flash its firmware is the same IP address as its normal user GUI, once unlocked. I was pondering if the "re-flash the firmware" GUI for the HH3.0B is identical to its normal user GUI -- that is 192.168.1.254   

That would have made more sense.

One thing we could try is modifying the CFE configuration so that it boots from the (h)ost PC (192.168.1.100) instead of from (f)lash. That's very simple. It involves changing the "r=f" parameter to "r=h" in the CFE config above.

Before re-fitting the NAND flash IC to the Home Hub PCB, it would be better to install a TSOP IC cradle to the board first, à la one of these, below.  At least then the flash can be readily removed without de-soldering, modified arbitrarily, and then refitted (repeat until the dirty deed of unlocking is done).

The HG612 was tweaked to do this - to retrieve its kernel from a tftp server running on the LAN.  But since the original kernel is hard-coded to mount the root file system from flash, there's nothing much achieved by net-booting.  Ideally, the kernel needs to be rebuilt to support an NFS root file system, so that can be mounted over the network.  When we tried this with the HG612, at the time, we didn't have Huawei's patches to the kernel source (specifically, the kernel driver for the ethernet switch controller, iirc) so it wasn't going to work.

Nits? Do you have a louse infestation?    I wear a flea-collar and find that keeps the nasties at bay! 

Yup, Our Wayne brought the head lice back from Boot Camp, a present for all the family, bless him! 

cheers, a

[burakkucat]

I tried that while I was fiddling about and got nothing until the normal web interface came up.

I looked through the bootloader block myself after I gave up but couldn't see anything else which might be a likely candidate.

Having now performed an nmap scan of IP address 192.168.1.254, after a "power-on with reset asserted", I can report that these ports are found to be open --

Code: [Select]

80, 161, 443, 631, 1780, 37215, 37443

I've made a note to perform another experiment (or two) by scanning the default IP address following a normal power-on.

[Hr155]

Hi Guys,
           Going back to the U.FL connectors on the Homehub 3 type b pcb ie J701 and J702
           any know  which is for 802.11n and which for 802.11b/g ?

          BTW U.FL connectors and pigtail leads now available in UK from CPC

        http://cpc.farnell.com/jsp/search/browse.jsp;jsessionid=GBVYNTAAEUKXWCQLCIRJN4Q?  N=411&Ntk=gensearch&Ntt=U.FL&Ntx=mode+matchallpartial&exposeLevel2Refinement=true&suggestions=false&ref=globalsearch&_requestid=143262

         Thanks in anticipation,
                                    Mike

[Hr155]

 
    Please disregard my earlier request - It turns out my Homehub 3 has a type A pcb !!!
     I therefore need to know which one is for 802.11b/g and which is for 802.11n
   
      Please help ASAP,
                              Mike

[burakkucat]

Sorry but I don't know anything about the HH3.0A. 

Have you checked with the folks over at PsiDOC?

[Howlingwolf]

Code: [Select]

80, 161, 443, 631, 1780, 37215, 37443


I got the same ones with power on/reset and under normal operation.

80 & 443 - Normal web interface.

1780 - "HTTP1.1 404 File not found".
37125 - "File not found".
37443 - HTTPS with a cert for zxserver. This also gives "File not found".

I suspect these might be related to a media server 'feature'.

161/631 - No response/"Bad Status Line". For some unknown reason I didn't make a note of which was which at the time and naturally I can't remember now. 

[burakkucat]

So to be absolutely sure, one of us should power up a HH3.0B and perform a factory reset via the "paper-clip" hole. Power cycle the device and then "nmap" scan each of the five ports that will accept an RJ-45 plug. Those five sets of results will form the base-line.

Next, power up the device whilst holding the reset "paper-clip" hole asserted and continue to hold it until the power light flashes amber. Now repeat an "nmap" scan on the five ports.

Finally, power up the device whilst holding the "finger" reset button asserted and continue to hold it until the power light flashes amber. Perform yet another set of "nmap" scans for the five ports.

I've made a note to remind myself to do the above but as cats live such busy lives, a distant relative of the common canis familiaris may get it done before me. 

[Howlingwolf]

Sorry to disappoint you old chap.

I'm afraid that Lupus Clamoris is up to his nostrils in it at the moment.

I will try to find some time for it this weekend but I can't promise anything.

[burakkucat]

I'm afraid that Lupus Clamoris is up to his nostrils in it at the moment.

That's to be expected when you play on a dung-heap! 

I've now performed 67% of the total experiment and just need to executed the five nmap scans, following on from a "finger on button" at power-up time reset. Once all fifteen results are logged, they will be considered and the observations reported here. 

[asbokid]

Looking forward to a progress report, burakkucat 

It wouldn't be easy but in theory it's possible to get the CFE bootloader running under MIPS emulation of QEMU, so as to determine its operation. That has been done before.   We've got a whopper bootloader here though - well over 100kBytes.  Wouldn't fancy reverse engineering much of that  Hopefully someone uncovers a much easier method of hacking the Home Hub 3.0b

cheers, a

[burakkucat]

One other port to be considered is that of the USB. Perhaps some thought should also be directed to it? 

[burakkucat]

Here are the results of those experiments.

To recap, there are five sockets that will accept an RJ-45 plug and two potential methods of powering-up the device (a paper-clip in the hole and a finger on the reset button) making ten separate experiments. To have something against which each result can be compared, a further five experiments needed to be performed to create the "baseline" data.

The raw experimental data captured is in the file nmap_scanning.txt, attached below. By considering that file, we see that the "finger on the reset button" experiments yield results identical to the "baseline" data.

Further considerations of the "Port 0", "Port 3" and "Port 4" experiments, "paper-clip in hole" method, showed that there was nothing of significance to note.

However there was an observed change for both "Port 1" and "Port 2". Please see the file results_log.txt, attached below.

Further investigations will now be appropriate.    But they will have to be performed on another day -- as its time for b*cat to find his bed.