Pfsense Nokıa IP380 Install

kankabir

I could not figure out yet. ip 380 remains idle

psykok

I could not figure out yet. ip 380 remains idle

Hi,

So I have made some test under Linux (I'm more familiar with linux as BSD system) and I got the same error at the beginning using a standard debian installation.

I tried the kernel option nousb but it was no sufficient to be able to boot correctly
After that I have built my own kernel without ramdisk and only with the needed driver (and without USB).
Now my IP380 is starting without any problem under Debian.

The next step is to build the same custom kernel for pfsense, if it is possible …
I think the only think to do is to disable all reference to USB driver.

Alex

stephenw10

Have you tried adding any of the following to /boot/loader.conf.local

hint.usb.0.disabled=1
hint.uhci.0.disabled=1
hint.ohci.0.disabled=1

Steve

psykok

Hi,

Unfortunatly adding the these option in the loarder.conf is not working.

I think is the same problem I had under Linux, disabling USB was not enough … I must remove all USB option in the kernel to have a booting OS.

Alex

psykok

Hi,

Good news, after 3days fight Pfsense 2.0 is up and running on my IP380

The process was not so easy for me because I'm not a bsd user.
Second point the csv port was blocked at work but hopefully there a some nice workaround using ssh tunneling :D

I you want to fix you installation just download the following tgz file and use it to replace the /boot/kernel folder on your pfsense boot media.

http://alexkachler.free.fr/perso/ip380/ip380_kernel.tgz

If you want to rebuild a new kernel, you can reuse my conf file (I have only removed RAID, USB, WLAN support):
http://alexkachler.free.fr/perso/ip380/pfSense_wrap.8.i386

ALex

pierref

@psykok:

Hi,

Good news, after 3days fight Pfsense 2.0 is up and running on my IP380

The process was not so easy for me because I'm not a bsd user.
Second point the csv port was blocked at work but hopefully there a some nice workaround using ssh tunneling :D

I you want to fix you installation just download the following tgz file and use it to replace the /boot/kernel folder on your pfsense boot media.

http://alexkachler.free.fr/perso/ip380/ip380_kernel.tgz

If you want to rebuild a new kernel, you can reuse my conf file (I have only removed RAID, USB, WLAN support):
http://alexkachler.free.fr/perso/ip380/pfSense_wrap.8.i386

ALex

Congratulations Alex!!! I downloaded your kernel and I am also able to boot. I had a little problem for mounting the disk, because I installed pfSense 2.0 from the live CD on a disk that was called /dev/da0 but on the IP380 host, the disk has to be called /dev/ad0. After changing the occurences of da0 into da0 into /etc/fstab, I was able to reboot.

But I have still issues with the NICs. Since my second reboot, I no longer have the menu for reassigning the interfaces, etc… but a root prompt (with no completion feature).

I would like to know if you had to change the config.xml file for spoofing the mac addresses.

Anyway, thank you very much for the custom compiled kernel.

Bien le bonjour là-bas (en France, je suppose)!

Pierre

pierref

Hi

I must have done something wrong: my WAN NIC has a inet6 IP address but not inet (4) IP address. This is the output of ifconfig dc3:

# ifconfig dc3
dc3: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
        options=80008 <vlan_mtu,linkstate>ether 00:00:00:00:00:00
        inet6 fe80::7422:d7c0:c46:842%dc3 prefixlen 64 scopeid 0x8 
        nd6 options=43 <performnud,accept_rtadv>media: Ethernet autoselect
        status: no carrier</performnud,accept_rtadv></vlan_mtu,linkstate></up,broadcast,running,simplex,multicast>

How is this possible? I have no inet6 DHCP server active at home…

psykok

hi,

Merci je suis bien en france :D

I have performed some test today on the box and pfsense is running without any problem.
I can assign all my 4 NICs. The configuration is kept over reboot or power failure by me.
I have not changed anything in the config.xml, the MAC addresses are generated automatically when I’m configure an interface.

I know that Nokia has released several version of the IP380. Currently I have two different version (grey and white box), both are now running pfsense. I have only some hardware issues with the grey box … it’s not always booting : (
Maybe there is some difference between the NICs.

Alex

pierref

Hello Alex

I also have an IP380 with a grey box. I have 8 NICs. fxp[0-3] (Intel EtherExpress Pro 10/100B Ethernet) at the right and dc[0-3] (Digital DC21143 Fast Ethernet) at the left. The Intel ones are running. The Digital ones not yet. Worse: sometimes, I have an interrupt storm detected on "irq10", which is the bios irq of the dc[0-3] NICs, and my webconfigurator becomes non responsive, needing a reboot at the serial console. It is possible to unplug the Digital NICs.

I could redesign my LAN for 4 NICs and forget about the 4 NICs at the left, but it is pity…

I suppose you don't have these Digital DC21143 Fast Ethernet in your configuration.

Anyway, the system is running and that's the most important.

Vive la France.

Pierre

psykok

Hi,

I have 6 NICS in my grey box, the 4 fxp and 2 other on the first extension card.

Unfortunately I have some trouble with this version, I think something is going wron on the hardware level because the box is not booting correctly.

On the other box I have only the 4 standard ports.

But for your problem if the Digital interfaces are visible using the command ifconfig the system has loaded some drivers for it.
If the driver is good working, that’s another point.

For the irq storm did you try to modify something in the bios?

Alex

psykok

So my gray box booted again and I have check the config of the additional NIC card.
Same error as you with the IRQ, the two port are detected but not working, the 4 default NICs are working without any problem.

I will check if there is some way to change the irq mapping on the firewall but I remember that the bios is a special light version with a very few available options.

pierref

When the system was running under IPSO, the Digital NICs used irq 11, 12 and 15.

If there is any way to assign other irq's to the Digital NIC's (through the device.hints file), it could solve the problem.

I would try something like adding some lines in the /conf/device.hints file, like

hint.dc.0.irq="10"
hint.dc.1.irq="12"
hint.dc.2.irq="13"
hint.dc.3.irq="15"

avoiding the irq that are already listed in the output of vmstat -i

Does this make sense? I am a software man, not a hardware guru.

pierref

Anyway, my entries in the device.hints file are not taken into consideration. Issuing vmstat -i shows the dc card is still using irq 10.

psykok

Did you check the bios if some irq setting is available?

I don't know if there is a way to force the irq for these nics.

Alex

wallabybob

In FreeBSD the calculated IRQ for a PCI device can be overridden by an entry in /boot/loader.conf.local (preferred since it won't be changed by a pfSense install) or /boot/loader.conf of the form:```
hw.pci1.2.3.INTA.irg=15


If you have a suitable IPSO installation or the startup output from a previous IPSO boot you should be able to determine the IRQs of each of the NICs. The challenge is then to map from the IPSO device name (e.g. eth-1, eth-s1p2) to FreeBSD device name (e.g. fxp1, dc2).

psykok

I give a try to your solution by modifying the /boot/loader.conf but it makes no difference.

It seems that the entry I write in the file are not affecting the kernel.
I use the following config:
hw.pci3.5.0.dc0.irq=12
hw.pci3.6.0.dc1.irq=13

I checked the pci addresse swith dmesg.

ALex

wallabybob

@psykok:

It seems that the entry I write in the file are not affecting the kernel.
I use the following config:
hw.pci3.5.0.dc0.irq=12
hw.pci3.6.0.dc1.irq=13

You should have used INTA rather than dc0 and dc1. See my post about this!

It might be helpful to have a bit of background on PCI devices. Each PCI device can use up to 4 interrupt request lines. They are called INTA, INTB, INTC, INTD. Most devices use INTA. The PCI interrupt request lines are connected to IRQs according to the whim of the motherboard designer. The /boot/loader.conf.local line```
hw.pci3.5.0.INTA.irq=12


As far as I know, there is no code that would act on a line like:```
hw.pci3.5.0.dc0.irq=12

The bus, device and function numbers you have used look plausible but I have no idea if they are correct.

Edit: I had the parameters in the loader variable name incorrect and consequently the suggested variables and values in this reply won't work.

pierref

Hi

First of all, my system is running even with interrupt storm on irq10.

The mapping of the NICs IPSO <-> pfSense can be deduced from the bootlog of IPSO, below:

eth-s1p1 <-> dc0
eth-s1p2 <-> dc1
eth-s2p1 <-> dc2
eth-s2p2 <-> dc3
eth1 <-> fxp0
eth2 <-> fxp1
eth3 <-> fxp2
eth4 <-> fxp3

This is confirmed by the experience of connecting stuff to these ports. The four first NICs, the Digital ones, are the left ones: eth-s1p2 stands for slot 1 port 2, the other ones are the Intel NICs.

From the same bootlog, I can extract the INTA, INTB, etc. and the corresponding irq, but not the PCI bus number. I don't know what "rev" and "onboard" stand for.

pcidec0 <intel 21154be="" 64-bit="" pci-pci="" bridge=""> rev 0 on pci1:0:0                
fxp0 <intel 10="" etherexpress="" pro="" 100b="" ethernet=""> rev 9 int d irq 6 onboard 1     
netlog:eth1 .. Ethernet address 0:a0:8e:78:c1:b4                               
fxp1 <intel 10="" etherexpress="" pro="" 100b="" ethernet=""> rev 9 int a irq 10 onboard 2    
netlog:eth2 .. Ethernet address 0:a0:8e:78:c1:b5                               
fxp2 <intel 10="" etherexpress="" pro="" 100b="" ethernet=""> rev 9 int b irq 11 onboard 3    
netlog:eth3 .. Ethernet address 0:a0:8e:78:c1:b6                               
fxp3 <intel 10="" etherexpress="" pro="" 100b="" ethernet=""> rev 9 int c irq 12 onboard 4    
netlog:eth4 .. Ethernet address 0:a0:8e:78:c1:b7                               
pcidec1 <intel 21154be="" 64-bit="" pci-pci="" bridge=""> rev 0 slot 1                     
tulip0 <digital dc21143="" fast="" ethernet=""> rev 65 int b irq 11 slot 1 port 1       
netlog:eth-s1p1 .. Generic 2114x DC21143 pass 4.1 -- 00:a0:8e:78:c1:ac         
netlog:eth-s1p1 .. enabling 10baseT/UTP port in half duplex mode               
tulip1 <digital dc21143="" fast="" ethernet=""> rev 65 int c irq 15 slot 1 port 2       
netlog:eth-s1p2 .. Generic 2114x DC21143 pass 4.1 -- 00:a0:8e:78:c1:ad         
netlog:eth-s1p2 .. enabling 10baseT/UTP port in half duplex mode               
pcidec2 <intel 21154be="" 64-bit="" pci-pci="" bridge=""> rev 0 slot 2                     
tulip2 <digital dc21143="" fast="" ethernet=""> rev 65 int b irq 15 slot 2 port 1       
netlog:eth-s2p1 .. Generic 2114x DC21143 pass 4.1 -- 00:a0:8e:78:c1:b0         
netlog:eth-s2p1 .. enabling 10baseT/UTP port in half duplex mode               
tulip3 <digital dc21143="" fast="" ethernet=""> rev 65 int c irq 12 slot 2 port 2       
netlog:eth-s2p2 .. Generic 2114x DC21143 pass 4.1 -- 00:a0:8e:78:c1:b1         
netlog:eth-s2p2 .. enabling 10baseT/UTP port in half duplex mode</digital></digital></intel></digital></digital></intel></intel></intel></intel></intel></intel>

For giving values for the PCI bus, I suppose I have to look into the bootlog of pfSense this time:

pci0: <serial bus,="" usb="">at device 15.2 (no driver attached)
pcib1: <serverworks nb6635="" 3.0le="" host="" to="" pci="" bridge="">pcibus 1 on motherboard
pci1: <pci bus="">on pcib1
pcib2: <pci-pci bridge="">at device 0.0 on pci1
pci2: <pci bus="">on pcib2
fxp0: <intel 10="" 100="" 82559er="" embedded="" ethernet="">port 0xec00-0xec3f mem 0xc0100000
-0xc0100fff,0xc0120000-0xc013ffff irq 11 at device 3.0 on pci2
fxp0: Disabling dynamic standby mode in EEPROM
fxp0: New EEPROM ID: 0xfffd
fxp0: EEPROM checksum @ 0xff: 0xffff -> 0xbbb9
miibus0: <mii bus="">on fxp0
inphy0: <i82555 10="" 100="" media="" interface="">PHY 1 on miibus0
inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fxp0: [ITHREAD]
fxp1: <intel 10="" 100="" 82559er="" embedded="" ethernet="">port 0xe800-0xe83f mem 0xc0140000
-0xc0140fff,0xc0160000-0xc017ffff irq 11 at device 4.0 on pci2
fxp1: Disabling dynamic standby mode in EEPROM
fxp1: New EEPROM ID: 0xfffd
fxp1: EEPROM checksum @ 0xff: 0xffff -> 0xbbb9
miibus1: <mii bus="">on fxp1
inphy1: <i82555 10="" 100="" media="" interface="">PHY 1 on miibus1
inphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fxp1: [ITHREAD]
fxp2: <intel 10="" 100="" 82559er="" embedded="" ethernet="">port 0xe400-0xe43f mem 0xc0180000
-0xc0180fff,0xc01a0000-0xc01bffff irq 11 at device 5.0 on pci2
fxp2: Disabling dynamic standby mode in EEPROM
fxp2: New EEPROM ID: 0xfffd
fxp2: EEPROM checksum @ 0xff: 0xffff -> 0xbbb9
miibus2: <mii bus="">on fxp2
inphy2: <i82555 10="" 100="" media="" interface="">PHY 1 on miibus2
inphy2:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fxp2: [ITHREAD]
fxp3: <intel 10="" 100="" 82559er="" embedded="" ethernet="">port 0xe000-0xe03f mem 0xc01c0000
-0xc01c0fff,0xc01e0000-0xc01fffff irq 11 at device 6.0 on pci2
fxp3: Disabling dynamic standby mode in EEPROM
fxp3: New EEPROM ID: 0xfffd
fxp3: EEPROM checksum @ 0xff: 0xffff -> 0xbbb9
miibus3: <mii bus="">on fxp3
inphy3: <i82555 10="" 100="" media="" interface="">PHY 1 on miibus3
inphy3:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fxp3: [ITHREAD]
pcib3: <pci-pci bridge="">at device 1.0 on pci1
pci3: <pci bus="">on pcib3
dc0: <intel 10="" 21143="" 100basetx="">port 0xdc00-0xdc7f mem 0xc0200000-0xc02003ff irq
 10 at device 5.0 on pci3
miibus4: <mii bus="">on dc0
bmtphy0: <bcm5221 10="" 100basetx="" phy="">PHY 1 on miibus4
bmtphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
dc0: [ITHREAD]
dc1: <intel 10="" 21143="" 100basetx="">port 0xd800-0xd87f mem 0xc0200400-0xc02007ff irq
 10 at device 6.0 on pci3
miibus5: <mii bus="">on dc1
bmtphy1: <bcm5221 10="" 100basetx="" phy="">PHY 1 on miibus5
bmtphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
dc1: [ITHREAD]
pcib4: <pci-pci bridge="">at device 2.0 on pci1
pci4: <pci bus="">on pcib4
dc2: <intel 10="" 21143="" 100basetx="">port 0xcc00-0xcc7f mem 0xc0300000-0xc03003ff irq
 10 at device 5.0 on pci4
miibus6: <mii bus="">on dc2
bmtphy2: <bcm5221 10="" 100basetx="" phy="">PHY 1 on miibus6
bmtphy2:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
dc2: [ITHREAD]
dc3: <intel 10="" 21143="" 100basetx="">port 0xc800-0xc87f mem 0xc0300400-0xc03007ff irq
 10 at device 6.0 on pci4
miibus7: <mii bus="">on dc3
bmtphy3: <bcm5221 10="" 100basetx="" phy="">PHY 1 on miibus7
bmtphy3:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
dc3: [ITHREAD]</bcm5221></mii></intel></bcm5221></mii></intel></pci></pci-pci></bcm5221></mii></intel></bcm5221></mii></intel></pci></pci-pci></i82555></mii></intel></i82555></mii></intel></i82555></mii></intel></i82555></mii></intel></pci></pci-pci></pci></serverworks></serial>

So, cross referencing both bootlogs, I suppose I have to put next settings in /boot/loader.conf.local (not in device.hints, by the way):

hint.pci2.3.0.INTD.irq="6"
hint.pci2.4.0.INTA.irq="10"
hint.pci2.5.0.INTB.irq="11"
hint.pci2.6.0.INTC.irq="12"
hint.pci3.5.0.INTB.irq="11"
hint.pci3.6.0.INTC.irq="15"
hint.pci4.5.0.INTB.irq="15"
hint.pci4.6.0.INTC.irq="12"

I am going to try later and I'll tell the results. If this doesn't make sense, please stop me before I risk to make my system unbootable.

psykok

By me if I check, I got the following information about the nics:

dmesg | grep dc
ubsec0: Broadcom 5802
dc0: <intel 10="" 21143="" 100basetx=""> port 0xdc00-0xdc7f mem 0xc0200000-0xc02003ff irq 10 at device 5.0 on pci3
miibus4: <mii bus=""> on dc0
dc0: [ITHREAD]
dc1: <intel 10="" 21143="" 100basetx=""> port 0xd800-0xd87f mem 0xc0200400-0xc02007ff irq 10 at device 6.0 on pci3
miibus5: <mii bus=""> on dc1
dc1: [ITHREAD]</mii></intel></mii></intel>

wallabybob

Based on the posting by pierref of the IPSO output (which gives the actual IRQs for the NICs), I suggest```

hw.pci3.5.0.INTA.irg=11
hw.pci3.6.0.INTA.irg=15

if the two NICs are in slot 1 and

hw.pci3.5.0.INTA.irg=15
hw.pci3.6.0.INTA.irg=12


The two NICs on the plugin cards are downstream of a PCI bridge which "swizzles" the interrupt lines. This may add a complication which I haven't accounted for. Please try the appropriate suggestion and report back the outcome. A further complication is that I'm not sure if the startup output reports the IRQ from the PCI configuration registers (wrong in many cases on IPSO systems) or the actual IRQ the software considers the device using. The output of pfSense shell command```
vmstat -i
```is probably the best report.