Alix 2c3 problems, kernel: pflog0: promiscuous mode enabled
-
Running on Alix 2c3 embeded release pfsense. Web gui is VERY slow if it works at all on the WAN port. I looked in the logs and found these errors:
Last 100 system log entries
Apr 10 00:23:05 last message repeated 3 times
Apr 10 00:23:05 kernel: pflog0: promiscuous mode enabled
Apr 10 00:23:05 kernel: pflog0: promiscuous mode disabled
Apr 10 00:22:42 kernel: pflog0: promiscuous mode enabled
Apr 10 00:22:41 kernel: pflog0: promiscuous mode disabled
Apr 10 00:22:33 kernel: pflog0: promiscuous mode enabled
Apr 10 00:22:33 kernel: pflog0: promiscuous mode disabled
Apr 10 00:22:06 kernel: pflog0: promiscuous mode enabled
Apr 10 00:22:06 login: login on console as root
Apr 10 00:22:06 kernel: pflog0: promiscuous mode disabled
Apr 10 00:17:23 kernel: pflog0: promiscuous mode enabled
Apr 10 00:17:22 login: login on console as root
Apr 10 00:17:22 kernel: pflog0: promiscuous mode disabled
Apr 10 00:16:52 dhcpd: For info, please visit http://www.isc.org/sw/dhcp/
Apr 10 00:16:52 dhcpd: All rights reserved.
Apr 10 00:16:52 dhcpd: Copyright 2004-2006 Internet Systems Consortium.
Apr 10 00:16:52 dhcpd: Internet Systems Consortium DHCP Server V3.0.5I'm not really doing anything special with it, so I'm not sure what is causing this. Anyone seen this before or have an idea? Thanks!
-
Here are some more logs:
Last 100 system log entries
Apr 10 00:40:39 check_reload_status: reloading filter
Apr 10 00:39:21 last message repeated 14 times
Apr 10 00:40:22 check_reload_status: starting sshd
Apr 10 00:39:21 kernel: pflog0: promiscuous mode enabled
Apr 10 00:39:20 kernel: pflog0: promiscuous mode disabled
Apr 10 00:39:15 kernel: pflog0: promiscuous mode enabled
Apr 10 00:39:15 kernel: pflog0: promiscuous mode disabled
Apr 10 00:39:10 kernel: pflog0: promiscuous mode enabled
Apr 10 00:39:09 kernel: pflog0: promiscuous mode disabled
Apr 10 00:38:51 kernel: pflog0: promiscuous mode enabled
Apr 10 00:38:51 kernel: pflog0: promiscuous mode disabled
Apr 10 00:38:48 kernel: pflog0: promiscuous mode enabled
Apr 10 00:38:48 kernel: pflog0: promiscuous mode disabled
Apr 10 00:38:46 kernel: pflog0: promiscuous mode enabled
Apr 10 00:38:46 kernel: pflog0: promiscuous mode disabled
Apr 10 00:38:41 kernel: pflog0: promiscuous mode enabled
Apr 10 00:38:41 kernel: pflog0: promiscuous mode disabled
Apr 10 00:38:37 kernel: pflog0: promiscuous mode enabled
Apr 10 00:38:36 kernel: pflog0: promiscuous mode disabled
Apr 10 00:38:31 kernel: pflog0: promiscuous mode enabled
Apr 10 00:38:30 kernel: pflog0: promiscuous mode disabled
Apr 10 00:38:26 kernel: pflog0: promiscuous mode enabled
Apr 10 00:38:26 kernel: pflog0: promiscuous mode disabled
Apr 10 00:38:22 kernel: pflog0: promiscuous mode enabled
Apr 10 00:38:22 kernel: pflog0: promiscuous mode disabled
Apr 10 00:38:19 kernel: pflog0: promiscuous mode enabled
Apr 10 00:38:19 kernel: pflog0: promiscuous mode disabled
Apr 10 00:38:16 kernel: pflog0: promiscuous mode enabled
Apr 10 00:38:16 kernel: pflog0: promiscuous mode disabled
Apr 10 00:37:58 kernel: pflog0: promiscuous mode enabled
Apr 10 00:37:57 kernel: pflog0: promiscuous mode disabled
Apr 10 00:37:56 kernel: pflog0: promiscuous mode enabled
Apr 10 00:37:54 login: login on console as root
Apr 10 00:37:54 kernel: pflog0: promiscuous mode disabled
Apr 10 00:37:09 login: login on console as root
Apr 10 00:36:39 init: getty repeating too quickly on port /dev/console, sleeping 30 secs
Apr 10 00:36:36 last message repeated 3 times
Apr 10 00:36:39 init: getty repeating too quickly on port /dev/console, sleeping 30 secs
Apr 10 00:36:37 kernel: pflog0: promiscuous mode enabled
Apr 10 00:36:35 kernel: pflog0: promiscuous mode disabled
Apr 10 00:36:32 kernel: pflog0: promiscuous mode enabled
Apr 10 00:36:32 kernel: pflog0: promiscuous mode disabled
Apr 10 00:36:28 kernel: pflog0: promiscuous mode enabled
Apr 10 00:36:27 login: login on console as root
Apr 10 00:36:27 kernel: pflog0: promiscuous mode disabled
-
That is truly bizarre.
-
Which bios version are you running. Some old bios versions had really strange issues.
-
Someone told me that pfSense doesnt run on v0.99, is that true? He said it hangs on boot.
Here is what I am running:
PC Engines ALIX.2 v0.98g
640 KB Base Memory
261120 KB Extended Memory01F0 Master 044A CF 1GB
Phys C/H/S 1966/16/63 Log C/H/S 983/32/63BIOS setup:
9 9600 baud (2) 19200 baud (3) 38400 baud (5) 57600 baud (1) 115200 baud
C CHS mode (L) LBA mode (W) HDD wait (V) HDD slave (U) UDMA enable
(M) MFGPT workaround
R Serial console enable
(E) Etherboot enable
(X) Xmodem upload
(Q) Quit
-
It works fine with the latest bios: http://pcengines.ch/alix2.htm
Upgrade and retest.
-
I have just upgraded the bios, here are the settings:
PC Engines ALIX.2 v0.99
640 KB Base Memory
261120 KB Extended Memory01F0 Master 044A CF 1GB
Phys C/H/S 1966/16/63 Log C/H/S 983/32/63BIOS setup:
9 9600 baud (2) 19200 baud (3) 38400 baud (5) 57600 baud (1) 115200 baud
C CHS mode (L) LBA mode (W) HDD wait (V) HDD slave (U) UDMA enable
(M) MFGPT workaround
(P) late PCI init
R Serial console enable
(E) PXE boot enable
(X) Xmodem upload
(Q) QuitI'm still getting the weird log entries:
Last 100 system log entries
Apr 10 15:31:20 login: login on console as root
Apr 10 15:31:19 check_reload_status: reloading filter
Apr 10 15:29:16 kernel: pflog0: promiscuous mode enabled
Apr 10 15:29:16 login: login on console as root
Apr 10 15:29:16 kernel: pflog0: promiscuous mode disabled
Apr 10 15:27:37 sshd[2073]: Accepted keyboard-interactive/pam for admin from 192.168.0.200 port 4189 ssh2
Apr 10 15:26:50 login: login on console as root
Apr 10 15:26:20 check_reload_status: updating dyndns
Apr 10 15:26:20 init: getty repeating too quickly on port /dev/console, sleeping 30 secs
Apr 10 15:26:18 last message repeated 3 times
Apr 10 15:26:20 init: getty repeating too quickly on port /dev/console, sleeping 30 secsI'm also having the same original problem of trying to manage the pfSense via the WAN port and having it be very slow, or time out all together. Sometimes when its slow, the text of the page will eventually load, but without the formattings, like it didn't download the css file or something similar.
I have attached a copy of my config file. I have removed the password hash.
Anyone have ideas? I think my next step will be to do a factory reset, setting things up by hand, and see if I still have the same problems.
-
What's the device at WAN? Maybe there is some autonegotiation problem. Some modems only do 10 mbit/s half duplex for example. Check status>interfaces to see what gets negotiated and of that makes sense. What cable are you using between wan and that device? Try a different cable, if it's a switch, try a different port. Even a longer cable might help in some situations in case it's a pretty short cable like a 0.5m cable. These extremely short cables sometimes cause problems when connecting 2 devices directly to each other. For example a special SIS chipset had problems with such a setup in the past.
-
Device at the WAN has been different with no change in the results. It is currently a cable modem, but was a dell switch.
WAN interface: Media 100baseTX <full-duplex>I have tried a few different cables, no change in result. None of them were very short.
I have used pfSense at many of my other locations without a problem. However they were all regular PC's with 3 NIC's installed. This is my first attempt at using an ALIX, and so far, I'm not impressed. I'm fairly certain it has something to do with the ALIX, or maybe the CF card, as the setup is not exotic. This can be seen by downloading the config file which I attached a few posts before.</full-duplex>
-
Can you try to swap the nics assignment (LAN<->WAN) and see if the problem moves to another interface then? If yes you most likely have a hardware problem with the one nic.
-
I have actually duplicated the problem on a different ALIX board, of the same model.
One thing I could try, would be to change NIC assignments, on the off chance that has something to do with it. Right now I'm assigning the NIC by the serial port as LAN, middle as OPT, and closest to power as WAN.
A friend of mine is having problems with pfSense on ALIX as well. I think the problem is probably some incompatiblity between pfSense and ALIX. I'm not sure if its the BIOS in ALIX, or driver issue. But something is definitely not working like the PC version that I'm used to.
-
I use alixes without issues and I know others do as well. It's not a general problem with that kind of hardware. What PSUs are you using? I have seen some funny problems with wraps that have been used with underpowered PSUs.
-
That is an excellent point. My PSU outputs 12 VDC @ 800mA. Positive on the inside, and negative on the outside of the connector.
What PSU's do you use?
-
I use the ones pcengines sell. Note that those are 18V, 800 mA: http://pcengines.ch/ac18veur.htm
-
The numbers I gave you are for the PSU is for the one I have here at home. I'm not even sure if the one at the client has the same stats. I'll have to check it tomorrow and let you know.
-
It looks like the problems are continuing to get weirder. Here are the latest logs:
Last 100 system log entries
Apr 11 15:52:06 php: : Not a valid interface action ""
Apr 11 15:52:06 php: : Processing -
Apr 11 15:52:06 php: : Not a valid interface action ""
Apr 11 15:52:06 php: : Processing start -
Apr 11 15:52:06 php: : Hotplug event detected for vr0 but ignoring since interface is not set for DHCP
Apr 11 15:52:06 php: : Processing vr0 - start
Apr 11 15:52:04 check_reload_status: rc.linkup starting
Apr 11 15:52:00 kernel: vr0: link state changed to UP
Apr 11 15:51:57 kernel: vr0: link state changed to DOWN
Apr 11 15:00:00 check_reload_status: check_reload_status is starting
Apr 11 13:50:44 php: : Not a valid interface action ""
Apr 11 13:50:44 php: : Processing -
Apr 11 13:50:44 php: : Not a valid interface action ""
Apr 11 13:50:44 php: : Processing start -
Apr 11 13:50:44 php: : Hotplug event detected for vr0 but ignoring since interface is not set for DHCP
Apr 11 13:50:44 php: : Processing vr0 - start
Apr 11 13:50:42 check_reload_status: rc.linkup starting
Apr 11 13:50:42 kernel: vr0: link state changed to UP
Apr 11 13:50:39 kernel: vr0: link state changed to DOWNI'm still planning on looking at the power supply tomorrow. At this point I think the problem is hardware. Either power supply or bad ALIX board.
-
The link seems to fall down frequently judging from the logs. That was my suspicion from the very begining. That's why I asked you to change cables, switchport, swap interfaceassignments, ….
-
I checked the PSU's today, and both of them are the same. I kind of doubt I got two bad ALIX boards, so maybe they don't like the PSU's I have?
-
I checked the PSU's today, and both of them are the same. I kind of doubt I got two bad ALIX boards, so maybe they don't like the PSU's I have?
I would try a different power supply. The ALIX manual states it can use 7 to 18V DC, but recommends an 18V 15W supply. Hoba's 18V 800mA power supply puts out 14.4 watts of power. A 12V supply comparable to that would need to be 1200mA. Seems to me like your 12V supply doesn't put out enough amperage.
-
lagreca,
Did a change in power supply resolve your issues?
I'm curious because my Alix 2c3 (bios .99) running 1.2 is freezing randomly with the occurrences being more frequent. I'm thinking my 12v 1.25a power supply may not be the cause.
Thnx,
Tony
-
Hopefully I will be getting a new PS for it today and will be able to test. I'll let you know what I find.
-
Tried with a Linksys WRT54G power supply today, 12v, 1,000ma. I'm still getting weirdness in the logs:
Last 100 system log entries
Apr 14 20:40:00 check_reload_status: check_reload_status is starting
Apr 14 14:50:21 php: : Not a valid interface action ""
Apr 14 14:50:21 php: : Processing -
Apr 14 14:50:21 php: : Not a valid interface action ""
Apr 14 14:50:21 php: : Processing start -
Apr 14 14:50:21 php: : Hotplug event detected for vr0 but ignoring since interface is not set for DHCP
Apr 14 14:50:21 php: : Processing vr0 - start
Apr 14 14:50:20 check_reload_status: rc.linkup starting
Apr 14 14:50:19 kernel: vr0: link state changed to UP
Apr 14 14:50:16 kernel: vr0: link state changed to DOWN
Apr 14 13:56:30 login: login on console as root
Apr 14 13:56:30 check_reload_status: check_reload_status is startingWill try again with a 12v 3.3amps or a 15v 1.2amps.
-
Could it be that your switch or whatever device you have on the other side of this link is broken?
My log looked similar when my ADSL-modem-router was in the proccess of dying…
Took me a while to figure that out since it was happening unregularly.
-
I suppose its possible. However, VR0 is the WAN interface, which is connected to the cable modem.
I guess a good test would be to hook an ALIX up at my house and see if VR0 goes up and down. If not, maybe the cable modem ethernet port is going bad?
-
I changed out my PS last night to an 18V 2.2 amp supply. It seems to have stopped the random freezing I was experiencing, but time will tell.
lagreca,
I'm getting the same messages as you on my vr0, even with the new power supply but I think my vr0 is my lan inteface (need to check tonight). I'm not sure what is causing it either but now I'm thinking it cold be a switch plugged into the vr0 port.
