Pfsense Install on Nokia IP390
-
Do it directly on the pfSense box:
[2.1.5-RELEASE][root@pfsense.fire.box]/conf(19): cd /tmp [2.1.5-RELEASE][root@pfsense.fire.box]/tmp(20): fetch https://sites.google.com/site/pfsensefirebox/home/readio readio 100% of 6207 B 4138 kBps [2.1.5-RELEASE][root@pfsense.fire.box]/tmp(21): chmod 0755 readio [2.1.5-RELEASE][root@pfsense.fire.box]/tmp(22): ./readio 0x480 Reading 480 :0/tmp is always read-write even in nano so that's easier but does get wiped at reboot.
Since it's such a small program I put it in /conf but that means mounting the filesystem RW first:
https://doc.pfsense.org/index.php/Remount_embedded_filesystem_as_read-write
There's also an option in Diagnostics: NanoBSD: to do it.You can also upload (or download) stuff to the pfSense box using WinSCP from Windows.
Steve
-
Alright, I ran readio from 0x480 to 0x487, here's the results:
As we can see, 0x486 is set to 0. What next?
-
Ok so we have selected GPIOs:
1bbc3180
0001 1011 1011 1100 0011 0001 1000 0000Selected as output:
1000ffff
0001 0000 0000 0000 1111 1111 1111 1111So things we are intersted in are:
–-- x-xx x-xx xx-- ---- ---- ---- ----Something to note though is that the default values for the GPIO select registers are 1b003100 thus there are 5 pins that have been set as GPIO when by default they are not. ;)
So lets read what the current values are at addresses 0x48e and 0x48f which correspond to the pins set as output.Steve
-
Alright, here's the results for 0x48e and 0x48f.
-
Ok, so:
1b3f
0001 1011 0011 1111
Comparing with bits that might be what we're looking for:
0000 1011 1011 1100That still leaves us with 7 possible bits/GPIOs. My money is on bit 21 since that is changes both select type and value from defaults.
So lets try changing it. Download and change the permissions on writeio from the same location.
We want to change 0x48e from 0011 1111 to 0001 1111 so:./writeio 0x48e 0x1fBare in mind that if this isn't the LED it may do something unexpected, like reboot the box if it happens to be connected to the reset button! On all 4 Watchguard boxes I played with nothing unexpected happened. Mostly just nothing happened! ;)
If nothing happens change 0x48e back to 0x3f and try one of the other bits.
Steve
-
Alright, so I tried writeio on 0x48e from 0x1f through 0x9f – Nothing happened, none of the LEDs turned on or off. All part of trial and error I guess!
Anyway, what next?
-
Try reading back the register you set to make sure it's actually setting correctly.
If you tried 1f-9f then that will have tried all 3 bits on that register. There are two bits on the lower half of the byte. You can try both at once by doing:
./writeio 0x48e 0x33If that does nothing then we can look at the bits in 0x48f.
Steve
-
Alright, I did a readio to confirm values are being written – Everything appears to have set correctly.
I also tried setting 0x48e to 0x33 , no change unfortunately.
So, on to 0x48f I guess! :P
-
Indeed. Set 0x48e back to 3f.
0x48f has 3 bit's we're interested in all in the lower half. So try setting it to:
0x13
0x19
0x1aSteve
-
Alright, I've tried those values on 0x48f, none of them appeared to change any of the LEDs.
What next?
-
Ok. The 6300ESB has a second set of GPIOs which include the 4 LED specific pins. The base address for these is 0x4b0 so please read all the registers between 0x4b0 and 0x4bb.
Steve
-
Alright, I ran those values. There's a few zeroes in here!
-
Ok so we have:
GPIO2 Use select register (default 03000000):
03000800
0000 0011 0000 0000 0000 1000 0000 0000GPIO2 IN/OUT register (default 00000000):
00000307
0000 0000 0000 0000 0000 0011 0000 0111GPIO2 level register (default 00000fff):
00000fff
0000 0000 0000 0000 0000 1111 1111 1111Ok so the level register is at the default values but there is one pin that has been enabled other than the default.
Interestingly this is where I found the LED in the X-Peak box. GPIO pins 40-43 are those capable of driving an LED directly which corresponds to the lower byte half of 0x4b9. Try./writeio 0x4b9 0x07Steve
-
Alright, I tried that writeio, no changes on any of the LEDs unfortunately. Charliew mentioned that the LEDs had drivers on the daughter board, so they may not be on the dedicated LED pins, although that doesn't really make sense if there is dedicated outputs for LEDs :s
What next? -
There is the possibility that a 1 at the GPIO register actually turns the LED off. So you could try the other pins that are GPIO enabled and set as output.
./writeio 0x4bb 0x03Steve
-
Any chance of getting your readio program running under IPSO? Or finding a native tool to do the same thing that might already be on the IPSO image? Comparing the values under pfSense and IPSO may give some clues, if possible.
-
Hmm. I tried that GPIO value on all of the values set to zero in the list, no changes. Something I did notice though was that the value was changing to 3, not 1 according to writeio.
And, apparently Stephenw said there isn't any kind of safety on the program, so, yes, in theory that might be a logical thing to do, get the ipso values and see how they're different. I'll try that in a sec.
-
It was compiled against FreeBSD 8.1 but still works in 8.3. However I think IPSO is based on FreeBSD 6 so who knows. The program is very simple so it may work. Which IPSO version is it?
Steve
-
6.2, released late 2010 I believe. I believe 6.2 is the last version of IPSO before the networking division of Nokia was bought by Checkpoint technologies.
Anyway, firing up IPSO now…
-
Something I did notice though was that the value was changing to 3, not 1 according to writeio.
What exactly did you mean by this?
Reading back through this it looks like we've tried all the pins. It's easy to overlook one though, if anyone wants to read back through the thread and check my work feel free!
There were several steps where we changed more than one GPIO pin in one go which could have potentially hidden the result but it seems unlikely given that there are several LEDs to be driven.Hmm. :-\
Steve
