Pretty much every network in the world has a good deal of broadcast noise. Until you get up to hundreds or thousands of hosts it's not enough to impact anything short of a host gone nuts spewing huge amounts of broadcast traffic (thousands of pps, which I've only seen happen a couple times that can be classified as just "host gone nuts", it's very rare). That's the reason you generally don't want more than a /24 per broadcast domain, more than 254 active devices on a network and you may have enough broadcast noise that it becomes an issue (though usually not until you get to several times that many hosts).

I've been looking into the sweeping after bootup issue. It seems that when a startup service fails, it keeps the leds sweeping.
I had a look at the beastie while it was starting up over the serial port, and noticed that I was having cron die immediately after starting up. I looked into the crontab. There was an entry for squid that didn't get removed when I uninstalled the package. After removing it, it seems to have cleared up the problem.

Nice.
Comprehensive set of screenshots there!  :)

Steve

Time To Crack:
1306628104 centuries
Total Passwords in Pattern:
4 Septillion

on firewall -> nat -> outbound nat

change mode to manual and add mapping rule with:

interface: outbound interface you want to force the ip(wan2 for example)

source: smtp server ip address

source port: any

destination: any

destination port: any or 25

nat address: interface address or virtual ip

it is crazy. At the morning, rrd catches some data….

status_rrd_graph_img.png
status_rrd_graph_img.png_thumb

Finally, I got it work.

My network is behind pfsense and untangle where untangle act as bridge. I did some research on untangle forum and the problem was the antivirus. Untangle scan every single file that I downloaded through IDM. Because of that scanning process, it prohibit me to have multiple connection. What I did, I just simply turned off the antivirus and now I get no problem with my IDM.

Thanks for your answer guys, I really appreciate it.

If you had non-functional DNS on the host and tried doing those lookups at that point, at times PHP has a nasty habit of hanging onto failed responses and refusing to issue new queries. Running 'killall php' at the console should resolve, or at worst, reboot.

The RRD traffic graphs are generated from PF counters. If you're not filtering on bridge member interfaces, rather only the bridge itself, the graphs of the member interfaces will be blank because there is no data for them.

For Windows you can use the shutdown.exe tool that was on IIRC the Win2K resource kit and is freely downloadable from MS. It also works with all newer versions of Windows. You could also pkg_add samba on the firewall and use a "net rpc" command to power down from there. Probably easier to do it from a Windows server if you have one with shutdown.exe.

after doing some further research i found out that the wrong password attemps happen near the time of the periodic reset.

manual reconnects do not cause this behaviour.

i will now try to capture a periodic rest with wireshark.

arnoldg, personally i think the only real secure way to do this is using VPN.  Follow the instructions on this video and it will work nicely.  This is the video that i used way back when i set mine up, works a charm:
http://www.youtube.com/watch?v=odjviG-KDq8

Killing from the console/ssh is fine if it's going nuts. I've seen rate do that before myself, but not in a repeatable way.

The usual way I see it is if I click on the traffic graph page accidentally and then navigate away from it really fast, but even that's not perfectly repeatable.

@miles267:

Thanks - that worked.  Is a pass phrase necessary for the key?

Well, technically it's not required, but it's a good practice security-wise to keep keys password protected.

If you do a lot of logins/logouts throughout the day, then you could use Pagent (in case of putty).

macraig you can see in console or system.log Watchdog timeouts on network interfaces ? I have a similar problem using Intel PRO 1000 MT Dual port PCI after minutes system hang

Stephen, thanks SO much for your patience and help.  In the end, I was able to restore libgcrypt from the FreeBSD archive site and install the appropriate version of freeipmi.  This restored both my bmc-watchdog functionality as well as added the ipmi-sensors function.  I too was able to add the IPMI Sensor entry to pfsense Diagnostics drop-down so I can access from within the web UI.  Much appreciated.

I have just tried this and It works, thanks to everyone who contributed.

I set this up on my BT UK service. I have a business account and have used the supplied username and password they email when you sign up. I think the following is default for domestic installs on BT, homehub@btinternet.com as the username and no password (set to 1234).

I should add this is a FTTC install and I replaced the BThub3 with my pfsense box

remember that some ISP's block ports under 1024 to "SCREW" their customers ….

Fixed that for ya!    ;D

On my LAN all nodes have public, fixed IP addresses, so as far as each computer's built-in firewall and/or the pfSense box allows, each one can access any other one regardless where it's located by a fixed IP address or FQDN.

This of course falls apart, as soon as a machine leaves the LAN, and that I try to prevent.

The one big thing that the Internet still has that's rather outdated is the geo-IP stuff, when in fact global roaming of any given IP address should be possible (just like a moble phone can be anywhere in the world and still be reachable by the same number).

So the goal is, to destroy the geo-location dependence of in practice a few, conceptually of all, my computers' IP addresses while retaining the ability to reach all of them by the same fixed IP address from any public network, regardless where they are located.

I'd like to end up with a logical environment that's largely independent from the physical location. e.g. an rsync script shouldn't have to know where a computer is. It should only need to know its public IP address and/or FQDN, and start working, as long as the host is reachable (if the laptop is sleeping in an airplane, it won't be reachable, but it shouldn't matter if it's set up in a hotel in Nairobi, a coffee shop half a mail away from the office, or in orbit on a space station: if there's internet connectivity, it should be reachable by the same address and FQDN.

Due to the boneheadedness of Verizon, I was already forced to virtualize my entire LAN by routing the public IP addresses over a VPN link to where I am, which means theoretically I could go traveling around the world with the entire LAN, IP addresses and FQDN's remaining invariant. So now I'd like to extend that concept to individual machines.

Bridging would be just fine, if somehow I could filter the broadcast traffic…

On a fast internet connection, the amount of broadcast traffic wouldn't be an issue, because there are not that many machines involved, and the net is generally fairly quiet, but traveling one doesn't always have a fast connection, and then broadcast traffic can quickly get deadly... (think GPRS link to the internet...)