Pfsense Install on Nokia IP390
-
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
-
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.
-
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.
-
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?
-
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.
-
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.
-
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.
-
That would have been nice but was a pretty long shot, FreeBSD has very few specialist drivers like that.
-
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#msg171469Steve
-
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? -
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
-
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=sharingI 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.
-
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.
-
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.
-
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
-
In fact it appears that ipsctl is more like sysctl but using a proprietary set of OIDs. It's not a driver itself, more a way of accessing various data needed by scripts.
If you're still running IPSO and have a console try running 'ipsctl -a' and see what's listed. Is it specific LED states or system states that trigger the LED via some other script?Steve
-
Haha, you've lost me.
I would appreciate it if you explain that in idiot terms, and, I can't seem to identify a SuperIO chip on the board. I know the Intel nhe6300 is an IO controller chip, but, my googling of the matter appears to hint that it's a small chip with a logo printed on it relating to the manufacturer and model no.
All my best guesses for the SuperIO chip turned out to be Texas Instruments I/O controllers or an Altera Logic IC.
Here's a picture of the board, see if you can identify a SuperIO chip:
I did run the ipsctl -a command, here's the output (warning: seriously long.)
http://pastebin.com/RE2wBKDP -
From the position of the other components I would say it's the chip in between the empty BIOS ROM socket and the diagnostic LED readout. Is that the Altera device?
Nokia may not have needed a SuperI/O chip since many of the features they offer aren't needed in an embedded application. I'd be surprised though since everything else is pretty much standard X86 stuff and the SuperIO chip is ubiquitous.Thanks for the output from ipsctl. We can see that the ledtool program as well as the other referenced ways to change the LEDs simply set the values in the hw:sys_stat:state:X and that something else is interpreting those states and setting the LED appropriately as well as whatever other action is required.
Steve
-
Yeah, that's the Altera chip. It's the Altera EPM570F256C5N. Appears to be a programmable logic controller. My guess would be that it might drive the diagnostic LED
Yeah, it does seem that way. The PCMCIA card slot is driven by a Texas Instruments IO controller, which I think might be a child of the Intel chip.
It's possible that the SuperIO is buried under a heatsink, however i'd prefer not to take those off as that might cause further complications on the board, although the heatsinks that I've identified are the processor, north and south bridge chipsets, and 2 ethernet controllers. I don't know what the heatsink that is arranged in 2 rows of lines might be.
So my guess would be then that whatever either runs off of ipsctl, or whatever ipsctl works on, is what actually reads and sets the LEDs.
Would A BIOS dump help at all in identifying what the SuperIO chip might be, if the board has one?
-
I've never seen a superio chip that required a heatsink so I doubt it's hidden. It could be on the bottom of the board. I think it's likely they used the Altera chip for whatever reason. They clearly didn't need a floppy controller or a parallel port or many of the other functions provided. Much of what used to be handled by superio is on the ICH anyway.
I would guess they used ipsctl to allow them to hold values from several different hardware types in a common format. It removes the drivers from the higher level scripts.
Anyway it doesn't really matter because we don't have access to the source code for whatever drivers Nokia did use. I suggest we proceed on the basis that the LEDs are likely controlled by the ICH.
Steve
