Pfsense Install on Nokia IP390

[stephenw10]

Yes, I was forgetting it's a BGA package and looking at the sheet most of the GPIO pins are on the inside anyway so it's unlikely you'd be able to see the tracks.

You could compile it against FreeBSD 6 (or whatever specific FreeBSD version that is built on). What is the result of:

uname -a

You could see what libc version you do have and symlink it to so.7. That can work but is bad practise.

Steve

[RBT-RS]

Here's the output for uname -a

I believe IPSO runs on FreeBSD version 6.x?

[stephenw10]

Ok, here's readio compiled on FreeBSD 6.2. Just remove the .png extension I had to pout that on because you're only allowed a few file types as attachments. Give that a try. As far as I can find IPSO 6.2 is built on FreeBSD 6.2 but it's hard to get any sort of definitive answer.
The MD5 should be 7deed0428bb423bbf803fb41b7d88d0a

Steve

readio6_2.png

[charliem]

Could be 6.2 or 6.1, based on the version file I posted earlier (https://forum.pfsense.org/index.php?topic=81292.msg446131#msg446131).  This executable is dynamically linked, so if that doesn't work, you could statically link it.  Personally, I would have broken out the black tape long ago  :)

[RBT-RS]

Alright, I ran readio on IPSO - here's the results:

A lot of ff going on here.

[stephenw10]

Hmm well that's no help at all. In fact it's suspicious that you're seeing only 'ff'. Perhaps the GPIO base isn't the same in IPSO. Try reading it from the pci config like we did earlier in pfSense.

Steve

[RBT-RS]

Here's the result from the pciconf

pciconf -l | grep isa
isab0@pci0:31:0:        class=0x060100 card=0x00000000 chip=0x25a18086 rev=0x02 hdr=0x00

Seems to be identical. In the readio, I did enter a random value to confirm that readio is working, and it did return a different value, maybe all those values are actually ff?

[stephenw10]

We need to read the pci config from the lpc device to see if the gpio base has been changed.

pciconf -r pci0:0:31:0: 0x58

Steve

[RBT-RS]

Here's the output:

saberhagen[admin]# pciconf -r pci0:31:0: 0x58
00000c81

[stephenw10]

Aha! A different gpio base. Which is interesting in itself, I thought that had to be setup by the bios.
Ok then please read the values:
0xc80 to 0xc87
0xc8c to 0xc8f
0xcb0 to 0xcbb

That should do it.  :)

Steve

[RBT-RS]

Alright, here's the readout:

[stephenw10]

Ok, that looks more like it. So lets look at what we have.
GPIO1 Select register
1bbc3180, same as it read under pfSense.
0001 1011 1011 1100 0011 0001 1000 0000

GPIO1 in/out register
1000ffff, same as pfSense.
0001 0000 0000 0000 1111 1111 1111 1111

GPIO1 output levels
1337??00 (You missed 0xc8d but that doesn't matter as those are inputs anyway  ;)). In pfSense these were 1b3f so that's an interesting change.
0001 0011 0011 0111
vs
0001 1011 0011 1111

Two bits that were 1 under pfSense are set as 0 in IPSO. If those do anything they should have shown up under our testing but we may have changed only one bit at at time which didn't show it for example.

GPIO2 Select register
03000e02,  under pfSense it read 03000800
0000 0011 0000 0000 0000 1110 0000 0010
vs
0000 0011 0000 0000 0000 1000 0000 0000
Three pins are additionally set as GPIO in IPSO and, perhaps importantly, two of them are in the special LED output register.

GPIO2 IN/OUT register
00000707, under pfSense it was 00000307
0000 0000 0000 0000 0000 0111 0000 0111
vs
0000 0000 0000 0000 0000 0011 0000 0111
Hmm the pins we were interested in here are set as input so not likely.

GPIO2 level register
00000fff, same as under pfSense
0000 0000 0000 0000 0000 1111 1111 1111

Ok, so it looks like there's only one possibility here and that's the changing of output levels on both GPIO1 pins. The additional GPIOs on GPIO2 are all set as input so can't be driving the leds.

Try these two settings under pfSense:

./writeio 0x48e 0x37
./writeio 0x48f 0x13

If that still does nothing we could try changing the state of the LED under IPSO using ipsctl or ledtool abd then re-reading the values to see if anything has changed.

Steve

[RBT-RS]

No luck unfortunately.

On a side note, the box which I run pfsense has a lot of ethernet ports, but only 2 of them work:

Eth4, on the far right of the unit, is the WAN port - em9 to pfsense.
In slot 1, the ethernet port on the left is the LAN port - em0 to pfsense.
How can I get the ports em1 to em8 working as LAN ports? Currently they don't do anything.. I've tried looking up tutorials but all of them are 6 years old and the options aren't even in pfsense any more.

I want all the ports to be on the 192.168.1.0/24 subnet – with pfsense using 192.168.1.1 as the management ip.

[charliem]

@RBT-RS:

On a side note, the box which I run pfsense has a lot of ethernet ports, but only 2 of them work:

Eth4, on the far right of the unit, is the WAN port - em9 to pfsense.
In slot 1, the ethernet port on the left is the LAN port - em0 to pfsense.
How can I get the ports em1 to em8 working as LAN ports? Currently they don't do anything.. I've tried looking up tutorials but all of them are 6 years old and the options aren't even in pfsense any more.

I want all the ports to be on the 192.168.1.0/24 subnet – with pfsense using 192.168.1.1 as the management ip.

So you want the extra ports to function as a switch?  That's not a normal use for firewall ports, and it's not something I've tried to warp pfSense into doing.  Why not just use a $20 switch that's optimized for that?  Unless I'm missing something …

[RBT-RS]

We already have a switch however the switch failed and I have no further budget to spend, so I need pfsense to act as a switch.. As you can see, there's no shortage of ports available

[stephenw10]

You will get people on here telling you not to do this for whatever reasons (cost, speed etc) but this looks like a very valid case. You need to bridge the ports. I wrote a guide some while ago:
https://forum.pfsense.org/index.php/topic,48947.msg269592.html#msg269592

Steve

[stephenw10]

The one final thing we can do to see if the led is controlled by the ICH is to set the LED in IPSO and then re-read the registers to see if anything has changed. So in IPSO try to set the yellow led on by running:

ipsctl hw:sys_stat:state:volt_alert=1

Now that should set the state which sets the LED but it  might also do some other stuff.

Steve

[RBT-RS]

@stephenw10:

You will get people on here telling you not to do this for whatever reasons (cost, speed etc) but this looks like a very valid case. You need to bridge the ports. I wrote a guide some while ago:
https://forum.pfsense.org/index.php/topic,48947.msg269592.html#msg269592

Steve

Hi Steve,

Just tried to follow this tutorial: I got to step 4, but, when setting the original LAN connection to the bridge0 interface, it just locks me out, and according to windows' ipconfig, doesn't assign IP addresses any more, and will only give an IPv6 gateway. No internet through it.
The config for the original LAN interface is as follows:

All the other interface are in the "none" for both IPv4 and IPv6.

[stephenw10]

Did you reconnect your client to one of the interfaces in the bridge? When you re-assign LAN the old interface will become inactive.

Did you set the sysctls before you created the bridge? If not then just reboot and the new bridge will be brought up with the new settings.
If you have somehow not configured the firewall correctly you can temporarily disable the firewall completely from the console while you add appropriate rules:
https://doc.pfsense.org/index.php/I_locked_myself_out_of_the_WebGUI,_help!#Remotely_Circumvent_Firewall_Lockout_by_Temporarily_Changing_the_Firewall_Rules

Steve

[RBT-RS]

Hmm. Yes, I did reconnect it to a bridge interface.

If you mean sysctls as in system tuneables, then yes.. If it's something else, then.. Nope.

I'll look into that if I have set the sysctls correctly