Actually, that is what I was thinking of. Few years ago, I did something like that. There was a parallel-port-based ISA card that we were able to access any of its 23 ports directly, turning them ON or OFF at will. I did a simple PCB with switching transistors that reset the modems and hung computers. Working with less than 12V, we didn't have to deal with complicated 120v regulation, certification, etc… May be it was sophisticated but it was a lot cheaper ;)
I am currently serving few small customers who can't afford few hundred dollars just to rest the modems. I'll use a simple timer that power cycle the modem every morning for the one that is having troubles right now.
I do not know how much difficult or simple it is to write a script that uses the router parallel (or serial) port as I do not have much experience programming under BSD.

Than you for the explanation, cmb!

I had never expected saving/importing/exporting ONLY the RRD data can be so troublesome…

The packages that I tested does not have this capability as well.

A few years ago I wouldn't even care to look at the RRD Traffic graphs as it didn't affected me, I guess time has definitely changed.  But now with monthly CAPS imposed by many-to-most major ISPs around the world, who can afford NOT to ignore how much traffic one uses.  Overages can be quite expensive!

Yep, I agree. I don't think it was necessarily the DNS forwarder. Upon further investigation I 'think' that I needed to check the 'Do not use the DNS Forwarder as a DNS server for the firewall' in the General Setup. At least that is what I did and it seems to be working now. I didn't have any other items checked in the 'DNS Forwarder' other than the 'Enable DNS Forwarder'. So I don't know what is going on, but it certainly is/was a DNS cache issue

@jimp:

It will be a while yet. It will most likely end up being a book for 2.1 since we intend to cover IPv6 there.

We've been so busy we haven't had time to write much. There are a lot of areas that will need quite a bit of work to be updated for 2.0.

All right.
thank you for those informations!

Regards,

Diag > Command will always show rw because it switches to rw to run your command.

Only when viewed from the shell on the console/ssh will you see ro.

Just wanted to finalize this thread out by saying I ended up swapping out both the nics. Their chipset numbers are: 88E8001-LKJ1 AJ476A.2 0714 A4P TW Marvell of some kind. Hardware version: B2

Now everything works fine except dealing with havp and squid now :)

Yes you can do that. Though I would probably stay away from doing so, or at least be very careful not to mess up the VLANs on any of your switches or you could end up with a layer 2 loop much more easily than bridging scenarios without VLANs.

You're welcome :)

@bsmither:

So, just to satisfy my curiosity, is it the ICMP protocol's job to determine if a reply can be sent without a route, or is it the networking part of the OS, or the ping.exe application?

The way I see it, something has to be dumb enough to permit a reply based on knowing the IP address and/or the MAC address of the sender in the request packet.

It's the IP stack of the OS. It has to be able to send back to the source IP of the request, whether it's locally reachable (so it just ARPs that IP), or is reachable via some router in its routing table (in which case it ARPs the router where that IP is reachable per its routing table).

You can turn on NXDOMAIN responses in OpenDNS. Or fix your DNS so it'll resolve local hostnames correctly, which is the better solution given that's what current Windows versions expect.

@stephenw10:

@Cino:

You just can't try a card in the box and expect it to be 100% stable without researching the wifi card and its driver for freebsd.

I think that says it all. For many people that is a reason why pfSense sucks. For a M$ based solution (and increasingly Linux) you can just try a card and have a reasonable expectation that it will work well.
As pfSense becomes more popular it is inevitable that more first time users are going to be disappointed. There are probably far more satisfied users but most of those don't complain.  ;)

Yeah this entire thread can be summarized as FreeBSD's wireless drivers for some cards really suck, and on the rest the guy has no idea what he's doing, things like creating MAC address conflicts and wondering why the network breaks.

But Linux has much the same issues with drivers, you really have to research your cards before you buy one especially since many of the bigger manufacturers (DLink, Linksys, etc.) will change the chipset used in their cards without changing the model # at all, so even finding a working model # on some cards is no assurance you're going to get the same card they used to sell under that model.

It looks like the situation with wireless will be getting a lot better with FreeBSD 9. Adrian Chadd has done quite a bit of work in FreeBSD 9 for a commercial software company that uses FreeBSD in their appliances and relies heavily on wireless. I have hopes that will be a great step forward on wireless.

I can kind of explain what's going on with the SMC gateway. Think of it as a router / firewall / modem all in one. Basically the device has several IP addresses assigned to it. IIRC there are actually two real world IPs on the device, one is only seen by comcast on the router's wan port, then there is another real world IP on the routers LAN port. The device routes traffic between these two IPs so you can get your live subnet. There is also a firwall that resides off of the router's lan port, which will do NAT. Both the router LAN and the NAT'ed firewall are live on all 4 ports of the switch. So when you put in the correct information for a static IP address, the pc will find the appropriate gateway and use that to get through the SMC router and to the internet. If you just use a DHCP lease that is handed from the SMC firewall and your traffic flows through that then into the SMC router and to the internet.

So it would look something like this:

COMCAST ROUTER
  |
  /
WAN SMC ROUTER PORT
  |
  /
LAN SMC ROUTER PORT -> FIREWALL
  |                                        |
  /                                      /
        4 PORT SMC SWITCH

It's kind of neat how it's setup because it is possible to use both static IPs and have clients behind the firewall at the same time. The networks don't really cross but if you had a packet sniffer on your lan it might be possible to see traffic from the other subnet. Obviously if this is a concern you would only use one or the other.

The other thing that you get is even with having only 1 static IP address you technically get 2, because a /30 gives 4 addresses.

I am also having same problem with Pfsense 2.0.

I am using multiple WAN connections and Squid + Squidgaurd. Every thing is working fine but FTP :( no luck I am tried same options as u did.

Well in my case if i connect to my FTP server. MY FTP server responds and did not show any listing of folders. and disconnect me after some time without showing anything. I have also tried this VIA Filezila to connect to FTP but have Error. EcoNNREFUSED.

Anyone please help us.

Thanks

/boot/loader.conf and /boot/loader.conf.local are for loader variables, not sysctls. Modify sysctls through System -> Advanced, click on System Tunables then click on the "+" at the bottom of the page to add a new entry.

The DGS-3100 has a slightly more complex VLAN setup, hence, the exact steps are as follows if you want to allow all LAN ports access to the Switch configuration (in this instance, you would use a computer on Ports 2-32 or 43-47 to access the switch management):

Go to L2 -> Asymmetric VLAN and enable it.

Go to L2 Features > Forward & Filtering >DLF Filtering Mode:
Select All (check the box), Select Forward all DLF packets.
Apply.

Go to L2 -> 802.1Q VLAN:

Edit Default VLAN (VID 1).
Select Ports 1 & 33-42 as non-members.
Select Ports 2-32, 43-47 as untagged.
Click Apply.

Click on the Add/ Edit VLAN tab.
Add a new VLAN with VID = 2, Name = LAN.
Select Port 1 as Tagged.
Select Ports 2-32 as Untagged.
Select Ports 33-48 as Non-member.
Click Apply.

Click on the Add/ Edit VLAN tab.
Add a new VLAN with VID = 3, Name = Freeswitch.
Select Port 1 as Tagged.
Select Ports 33-42 as Untagged.
Select Ports 2-32, 43-48 as Non-Member.
Click Apply.

Click on the Add/ Edit VLAN tab.
Add a new VLAN with VID = 4, Name = Wifi.
Select Port 1 as Tagged.
Select Port 48 as Untagged.
Select Ports 2-47 as Non-Member.
Click Apply.

You MUST reboot your FW and all be "recognized"  ( you will be able to choose the database in FusinPBX menu )