Feedback and little probelms with 2.2-rc
-
Hello,
I am new to pfSense. Since I don't have an installed base (yet), I decided to check out the 2.2-RC in order to help the project by providing a little bit of testing from a newbee perspective.
I used the embedded 2g AMD64 image with serial console on an APU.1D4 hardware with an 120GB SSD.
Here are some of my findings:
1. (most annoying): After a reboot, the WAN interface (DHCP) won't come up automatically. I have to unplug the WAN cable and plug it again, then it comes up. I could not find any configuration setting to force the WAN interface to come up automatcally.
2. Once installed, the configuration seems to be stored somewhere on the SSD. When I try to reinstall (from USB-Stick again), then this stored configuration will be reused without any question. I find it somewhat irritating that there is no obvious way to wipe this configuration and do a reinstall from scratch. Even the "Factory reset" menu won't wipe the interface assignment. You have to invoke a different menu item to re-assign the interfaces. And it is still not clear to me whether there are more settings which need to be wiped by some other procedure.
3. While the USB stick keeps the serial speed of 115200 that is set by the BIOS, the installed system sometimes switches to 9600 and sometimes doesn't. I know there is the setting in the webgui to select 115200. But this setting seems also to be something that won't be wiped (as described in bullet 2.) so it's not always clear whether to expect a bootup with 9600 or with 115200.
4. Once, the boot (after calling the reboot option from the webgui) ended up in a root prompt instead of the menu. The system ended up in a non-operating state, which would be a major annoyance in a productive environment. Unfortunately, due to bullet 3., I have no idea what messages were displayed before the boot prompt.
I hope my remarks will be of some help to the project, even though my bad English. Should I keep on with 2.2-rc or should I go to the stable release?
-
Thanks for your feedback. Which exact filename are you writing out re: the embedded 2g image? Some of that seems like maybe you're writing out an update image rather than a full image, which would probably explain a variety of the remainder of what you describe. Are you using a USB flash drive or SD card for that?
1. (most annoying): After a reboot, the WAN interface (DHCP) won't come up automatically. I have to unplug the WAN cable and plug it again, then it comes up. I could not find any configuration setting to force the WAN interface to come up automatcally.
There isn't such a setting, as there isn't any way to make it not come up automatically. Anything unusual about your setup or configuration? What does Status>Interfaces show for WAN post-boot (before unplug/re-plug)? What's shown for dhclient in the DHCP log (Status>System logs, DHCP)?
-
Sorry for the late response. I already tried to reply some weeks ago, but IIRC, I needed too long to compose the reply, so that the timeout on the forum software hit me and my reply got lost.
@cmb:
Thanks for your feedback. Which exact filename are you writing out re: the embedded 2g image?
pfSense-2.2-RC-RELEASE-4g-i386-nanobsd.img.gz
Some of that seems like maybe you're writing out an update image rather than a full image, which would probably explain a variety of the remainder of what you describe. Are you using a USB flash drive or SD card for that?
I use an USB thumb drive.
1. (most annoying): After a reboot, the WAN interface (DHCP) won't come up automatically. I have to unplug the WAN cable and plug it again, then it comes up. I could not find any configuration setting to force the WAN interface to come up automatcally.
I fount the problem for this: Auto-negotiation was not working. I am somewhat surprised about that, since I have not seen such problems since the early days of 100BaseT :o
Setting fixed port speed helped here.
But I still wonder whether the LAN interfaces on the APU.1D4 (realtec?) are that old? Or is this an issue with the driver for the LAN interfaces?Any hints how to completely wipe the configuration when doing a new install?
-
But I still wonder whether the LAN interfaces on the APU.1D4 (realtec?) are that old? Or is this an issue with the driver for the LAN interfaces?
It's not that they're old, but there are hardware quirks on those Realtek chipsets in certain circumstances. One is that it's impossible to disable Ethernet autonegotiation (on FreeBSD, OpenBSD and Linux), the driver sends the appropriate thing to the NIC, and it does nothing with it. We reported it to PC Engines, who replied that they weren't surprised and are looking to replace them with Intel NICs in a future board. While it doesn't actually disable autonegotiation, maybe it does change something in the NIC that works around some other problem it has with interoperability with your modem.
Generally speaking, you should never disable autonegotiation (unless it's equivalently disabled on the device you're plugging into) as you'll end up with a duplex mismatch, but since those Realteks won't actually disable autonegotiation, you're fine.
Any hints how to completely wipe the configuration when doing a new install?
When you write out a new image, you have a completely fresh config. Or option 4 at the console to reset to defaults will do the same.
-
@cmb:
But I still wonder whether the LAN interfaces on the APU.1D4 (realtec?) are that old? Or is this an issue with the driver for the LAN interfaces?
It's not that they're old, but there are hardware quirks on those Realtek chipsets in certain circumstances. One is that it's impossible to disable Ethernet autonegotiation (on FreeBSD, OpenBSD and Linux), the driver sends the appropriate thing to the NIC, and it does nothing with it. We reported it to PC Engines, who replied that they weren't surprised and are looking to replace them with Intel NICs in a future board. While it doesn't actually disable autonegotiation, maybe it does change something in the NIC that works around some other problem it has with interoperability with your modem.
Generally speaking, you should never disable autonegotiation (unless it's equivalently disabled on the device you're plugging into) as you'll end up with a duplex mismatch, but since those Realteks won't actually disable autonegotiation, you're fine.
Huh? I have a hard time to understand this. What I did, was to disable autonegotiation by setting a fixed speed. And that solved the problem. So how comes that the problem was solved although the realtec ignores this "disable"?
Any hints how to completely wipe the configuration when doing a new install?
When you write out a new image, you have a completely fresh config. Or option 4 at the console to reset to defaults will do the same.
As I wrote in my original post, I did:
-
An install from scratch - old config happily survived
-
Factory-reset - Old interface assignments (and maybe other settings? I don't know) still survived
-
Called the menu to re-assign the interfaces - How can I be sure everything else is at factory reset? Since the interface settings survived the factory reset, maybe some other settings survived too?
-
-
Huh? I have a hard time to understand this. What I did, was to disable autonegotiation by setting a fixed speed. And that solved the problem. So how comes that the problem was solved although the realtec ignores this "disable"?
-
An install from scratch - old config happily survived
-
Factory-reset - Old interface assignments (and maybe other settings? I don't know) still survived
-
Called the menu to re-assign the interfaces - How can I be sure everything else is at factory reset? Since the interface settings survived the factory reset, maybe some other settings survived too?
-
-
-
An install from scratch - old config happily survived
-
Factory-reset - Old interface assignments (and maybe other settings? I don't know) still survived
-
Called the menu to re-assign the interfaces - How can I be sure everything else is at factory reset? Since the interface settings survived the factory reset, maybe some other settings survived too?
The NICs in the default config are assigned as em0 and em1, so on that hardware, a reset to factory defaults would leave you having to re-assign interfaces. The installation process wipes out the entire storage medium, so there's no way that config survived on there. You have an SD card in it that has the config on it that's getting loaded maybe? Your USB flash drive would be completely clean upon rewriting the nano image to it.
I have no idea where the config managed to survive.
-
I did not use a CF card at all
-
I used the dd program on linux to write the image onto the raw USB thumb drive. That should have wiped everything what was stored before on that drive, IMHO
My UNIX knowledge comes mostly from linux, so I have no clue about the partitioning scheme on BSD. AFAIK, the partitions are somehow further divided into slices or something. Maybe one of those slices on the SSD happened to survive somehow?
Maybe the config is stored on the USB thumb at some point (e.g. when booting life and before choosing the "install" menu)? That might be an explanation: when doing a second install without re-writing the image onto the USB drive with dd, the interface assignment (which happens before the "install" menu can be chosen) might have survived on the USB drive. Although I am sure, I did the "dd" operation multiple times, I can not swaer that I did the "dd" before every installation attempt.
-