Pfsense Install on Nokia IP390

stephenw10

I agree there's probably some voltage or current regulation. The outputs from the ICH are probably not capable of sinking enough current to drive the LEDs directly so instead there are transistors for each LED (Q1, Q2 etc) and a line driver/buffer (the 7407 IC). The other large device, labelled 10-16L, is a capacitor perhaps to filter switching spikes. I like that there's a mystery space for an LED, CR9, that Nokia decided not to use for whatever reason. :)

Do the 4 LEDs come on as soon as you power on the box? Do they vary at all during boot?

The BIOS setup in embedded hardware like these boxes is often available on the serial console via 'console redirection'. It's usually at a baud rate of 115200bps. To access it you often have to press TAB because you can't send DEL over serial. Interestingly it looks like that box has two BIOS ROM chips.

Edit: Maybe on the other serial port, AUX, perhaps.

Steve

RBT-RS

You're correct. The board has support for 2 BIOS chips, but only the right one is populated with a BIOS chip. According to the stickers on the MB, the BIOS is an American Megatrends AMI BIOS 786Q.

As for accessing the BIOS, I'll give that baud rate a try tomorrow. How will I know when I'm in the BIOS? Will it print text like the normal 9600 baud rate does?

I believe that the LED for CR9 Might be for and LED for the IP560. I don't exactly know what that LED would be, but I would imagine that Nokia use the same status LED boards across most of their IP series products to save money.

stephenw10

Searching for info on the IP390 there are a number of people who have posted IPSO boot logs and it includes the memory count. That is before the bootloader so it's coming from the BIOS. It's in the same log at the same baud rate so I would suggest whatever baud rate IPSO uses should be good for accessing the BIOS setup. If you're seeing the memory count you're probably good, try pressing TAB. Of course Nokia could have it all shut down deliberately to stop access but they haven't forced only signed boot images for instance.

Steve

stephenw10

Just for reference the IP530 uses the SuperIO chip to control those LEDs:
http://www.coreboot.org/Board:nokia/ip530#Front_LEDs
Does not mean the IP390 does though. ;)

Steve

RBT-RS

Alright, I just managed to get into the BIOS by pressing tab after the memory test had completed.
It came up with a message:

American Megatrends AMBIOS (version #)
Press ~~ to enter setup.~~

It wouldn't allow me to enter text on that screen.
Here's pictures of the BIOS:
http://s26.postimg.org/j5bb13bi1/bios1.png
http://s26.postimg.org/mq76kbg1l/bios2.png
Here's inside the SuperIO menu:
http://s26.postimg.org/j7v6nxf5l/bios2_5.png
http://s26.postimg.org/fpj6rje9l/bios3.png
http://s26.postimg.org/41p4wzp4p/bios4.png
http://s26.postimg.org/cl8iuqxh5/bios5.png
http://s26.postimg.org/f3u7vfj7d/bios6.png

That's all of it. There doesn't appear to be any options for the status LEDs on the front panel.. Any ideas?

Sidenote: I should have said the IP690, not IP530. The IP690 is the model up from the 390.

stephenw10

It was worth looking, only one of the Watchguard boxes had a custom bios menu for the led. If it is connected to the ICH it's worth looking in the southbridge setup menu.
I assume that the yellow warning led comes on as soon as you power up the box and then just stays on?

Steve

RBT-RS

Here's a picture of the southbridge menu:

Yeah. On boot the only LED which does not switch on is the System fault. All the other LEDs, System activity (Is meant to be on), System warning (Should not be on) And System Power (Should be on) Are all on.

charliem

Any chance something shows up as /dev/led* or /dev/gpio*? If one or both show up under IPSO, but not pfSense, that could be a big clue.

RBT-RS

Hmm. I see what you're getting at, but how can I check if /dev/led* or /dev/gpio* show up under IPSO? What command should I enter?

charliem

@RBT-RS:

Hmm. I see what you're getting at, but how can I check if /dev/led* or /dev/gpio* show up under IPSO? What command should I enter?

Do you get a shell prompt on the serial console with IPSO? If not, try the AUX port, which is set up for remote management via modem. Or try to ssh into the unit.

For pfSense, you can use the shell on the serial console, or ssh in to the unit. Choose '8' from the menu, then use 'ls' command:

*** Welcome to pfSense 2.2-ALPHA-pfSense (amd64) on pfsense ***

 WAN (wan)       -> bge1       -> v4/DHCP4: xx.yyy.zzz.12/20
 LAN (lan)       -> bge0       -> v4: 192.168.2.128/24
 OPT1 (opt1)     -> bge1_vlan2 -> v4: 192.168.100.5/32

 0) Logout (SSH only)                  8) Shell
 1) Assign Interfaces                  9) pfTop
 2) Set interface(s) IP address       10) Filter Logs
 3) Reset webConfigurator password    11) Restart webConfigurator
 4) Reset to factory defaults         12) pfSense Developer Shell
 5) Reboot system                     13) Upgrade from console
 6) Halt system                       14) Disable Secure Shell (sshd)
 7) Ping host                         15) Restore recent configuration

Enter an option:

[2.2-ALPHA][root@pfsense.localdomain]/var/log(1): ls -l /dev/gpio* /dev/led*
ls: No match.

The ls command would be the same in either IPSO or pf Sense.

RBT-RS

I'm getting no output on the AUX port under pfSense, and the console port gets to "bootup complete" and won't accept further input. I'll try to ssh to pfSense in a minute.

RBT-RS

Alright, I managed to get the pfSense shell working through the serial port - There was an option under System > Advanced to enable the serial console.

So I booted into the shell, and ran that ls command:

And the same command under IPSO:

As you can see, IPSO didn't find anything under /dev/led* or /dev/gpio* … Any more ideas? Thanks for helping by the way.

stephenw10

That would have been nice but was a pretty long shot, FreeBSD has very few specialist drivers like that.

stephenw10

You have two options here (three if you decide it's just not worth the trouble!):
Modify the BIOS to turn off the LED at boot. It's probably one of the settings in the BIOS tables that are fairly easy to spot.
Switch it off after boot using a custom utility.

Both of those require knowing where the LED is driven from. Modifying and then flashing the BIOS is inherently risky.
I would certainly be willing to work with you to find the LED if you wish. You can read the posts in the arm/disarm led thread where ifloris and I found the location on the X-core box without me having access to it: https://forum.pfsense.org/index.php?topic=32013.msg171469#msg171469

Steve

RBT-RS

Yeah, I think option 2 would be the best option, given that if I was to flash the BIOS i'd have to go buy a few bits of hardware to get the new bios on the chip, and a couple of BIOS chips so I don't need to overwrite the original.

Should I upload the original IPSO kernel so you can take a look through it?
Also, would the readio and writeio programs work on the IP390 do you think?

stephenw10

You wouldn't need any additional hardware to flash the bios. You can do it from within pfSense the flashrom utility (available as a FreeBSD package) or boot a DOS image somehow and use AMI's flash utility. Though if you want to keep the original chip you would. The two bios sockets might introduce to extra unknowns. You can extract the existing BIOS to see if it gives us any clues using flashrom relatively risk free.

I'm not sure you've understood quite what the kernel is (I apologise if I'm wrong!). Looking through the IPSO file system for clues would help though. There is probably some script that calls the custom driver to change the LED for example.

The readio and writeio programs will certainly work. They have almost no saftey features that might stop them working!

Steve

RBT-RS

Hmm. I'd need to find out how that works before I'd do that.

Probably, I believe it to be the base-level system which interacts with the hardware?

Haha, I think then that it's only a question of trying to extract any clues from IPSO and the fun matter of trying to get them into pfSense.

Anyway, I think the next logical step is to give you a copy of IPSO to look through:
https://drive.google.com/folderview?id=0B4fVBOx_qVyRaktqMk9yaHF6UW8&usp=sharing

I don't really know where to start looking in the system files, but I did take a look at a few which appear to be FreeBSD config files.

charliem

@RBT-RS:

I don't really know where to start looking in the system files, but I did take a look at a few which appear to be FreeBSD config files.

Read through the /etc/ledtool and /etc/install_from_rstg scripts; unfortunately /etc/ledtool contains this:```

This doesn't manipulate the LEDs directly. Instead, it uses 'ipsctl' to

tell the IPSO kernel about a condition, and the IPSO kernel will blink

the LEDs appropriately for that condition.

RBT-RS

Hmm. That does complicate things, however, that DOES give us the script which controls the LEDs. According to Stephenw10's method of getting the LEDs working, as long as we know where the I/O for the LEDs are we should be able to modify the ledtool script to print directly to the LED panel. But, as I feared, the script currently sends the LED commands to the kernel, so we need to find the IDs of the front panel LEDs before any progress can be made.

Also, the file appears to reference /bin/ipsctl often, I'm thinking that's where we might find our I/O controller. However, I tried to open ipsctl, and it needs decrypting / unpacking, as it's not in any kind of readable format.

stephenw10

I would abandon any attempt at decompiling the ipsctl driver. The best clues in the Watchguard OS were in the comments such as Charlie found.
We do now know for sure that the LEDs are software driven and not fed from some on board hardware monitor chip so we can go looking for them knowing they exist. :)

Since the cable is so close to the ICH I would start by trying the GPIOs on that. If none of those work then look at the SuperIO chip. Can you see what the SuperIO is on that board? It would help tremedously if it's Winbond because that's what I know. The ICH GPIOs are much easier to test also.

Steve