Not that I'm aware of. If it were to happen, it would be on 2.2 or later.

@ermal:

Ok it was an issue with qstats.
Should be fixed with tomorrow snapshots.

Thanks ermal!

thats the problem…

1 duplicated (with changing IP, Interface) one old interface to the new one i CHANGED the settings of the new interface to "no monitoring" and it's saved again as new interface :(

(btw... in common we have an AS with 2 gateways ... and so 2 gateways on same interface for IPv4 and for IPv6)

That's the best way, avoid the reflection entirely :-)

Mobile users only show in the list if they're using xauth username/password authentication. If they're only using pre-shared keys, then it can't see them.

Hi, need some help.

Trying to configure a e392-u12 but can't add or modify PPPs connection.

My system:
Intel(R) Celeron(R) CPU E1200 @ 1.60GHz, dual intel NIC, Atheros Wifi nic.

Pfsense Version:
2.1-BETA1 (amd64)
built on Wed May 8 16:38:46 EDT 2013
FreeBSD 8.3-RELEASE-p8

Network config:
Wan in pppoe (using a ADSL modem)
Lan in Brigde NICs: em1 <-> ath0
2 wireless SSID

I'm trying to use e392 as wan backup or a default Wan, depends the stability. I install the patch http://files.nyi.pfsense.org/jimp/patches/3g_alt_detect.diff, but nothing change.

Interfaces XML:

<interfaces><wan><if>pppoe0</if> <spoofmac><alias-address><alias-subnet>32</alias-subnet> <enable><blockpriv><blockbogons><ipaddr>pppoe</ipaddr></blockbogons></blockpriv></enable></alias-address></spoofmac></wan> <lan><enable><if>bridge0</if> <spoofmac><ipaddr>10.0.0.1</ipaddr> <subnet>24</subnet></spoofmac></enable></lan> <opt1><if>ath0_wlan1</if> <wireless><standard>11g</standard> <protmode>cts</protmode> <txpower>99</txpower> <channel>11</channel> <txantenna>0</txantenna> <rxantenna>0</rxantenna> <distance><regdomain>etsi</regdomain> <regcountry>PT</regcountry> <reglocation>anywhere</reglocation> <mode>hostap</mode> <ssid>Something_Gest</ssid> <authmode><wpa><macaddr_acl><auth_algs>1</auth_algs> <wpa_mode>1</wpa_mode> <wpa_key_mgmt>WPA-PSK</wpa_key_mgmt> <wpa_pairwise>CCMP</wpa_pairwise> <wpa_group_rekey>60</wpa_group_rekey> <wpa_gmk_rekey>3600</wpa_gmk_rekey> <passphrase>*******</passphrase> <ext_wpa_sw><enable></enable></ext_wpa_sw></macaddr_acl></wpa> <auth_server_addr><auth_server_port><auth_server_shared_secret><auth_server_addr2><auth_server_port2><auth_server_shared_secret2></auth_server_shared_secret2></auth_server_port2></auth_server_addr2></auth_server_shared_secret></auth_server_port></auth_server_addr></authmode></distance></wireless> <enable><spoofmac><ipaddr>10.0.2.1</ipaddr> <subnet>24</subnet></spoofmac></enable></opt1> <opt3><if>em1</if> <enable><spoofmac></spoofmac></enable></opt3> <opt4><if>ath0</if> <wireless><mode>hostap</mode> <standard>11g</standard> <protmode>cts</protmode> <ssid>Something_Wifi</ssid> <channel>11</channel> <authmode><txpower>99</txpower> <distance><regdomain>etsi</regdomain> <regcountry>PT</regcountry> <reglocation>anywhere</reglocation> <wpa><macaddr_acl><auth_algs>1</auth_algs> <wpa_mode>3</wpa_mode> <wpa_key_mgmt>WPA-PSK</wpa_key_mgmt> <wpa_pairwise>CCMP TKIP</wpa_pairwise> <wpa_group_rekey>60</wpa_group_rekey> <wpa_gmk_rekey>3600</wpa_gmk_rekey> <passphrase>*****</passphrase> <ext_wpa_sw><enable></enable></ext_wpa_sw></macaddr_acl></wpa> <auth_server_addr><auth_server_port><auth_server_shared_secret><auth_server_addr2><auth_server_port2><auth_server_shared_secret2><txantenna>0</txantenna> <rxantenna>0</rxantenna> <pureg><enable></enable></pureg> <apbridge></apbridge></auth_server_shared_secret2></auth_server_port2></auth_server_addr2></auth_server_shared_secret></auth_server_port></auth_server_addr></distance></authmode></wireless> <spoofmac><enable></enable></spoofmac></opt4></interfaces>

If you need more information, feel free.

Edited: I have to put manually $serialports = glob("/dev/cua?[0-9]{,.[0-9]}", GLOB_BRACE); in interfaces_ppps_edit, now i can see the advanced options, doesn't help me but that is another story.

Thanks

Since you linked the FreeBSD PR's i answered that we already do that during bootup.
Check your system logs for any message like the one i put in there to see if maybe that is the case that it does not come up on bootup.

If not something else is happening in your system.

@phil.davis:

When you choose DHCP for an interface, the gateway is created automagically and gets set at run-time to the gateway provided by DHCP.
When you choose Static IP, then for a WAN link you need to pick a gateway on the Interfaces settings screen. I have a suspicion that when you just use System:Gateways:Edit gateway page and choose an interface, it doesn't put the "backward-pointer" in the Interface settings pointing back at the gateway entry. I'll try that when I get access to my test system in a few hours.

You can add as many gateways as you like. When you select the Interface field while adding a gateway it is just "Choose which interface this gateway applies to." - you are telling the system that this is a potential gateway for the selected interface, not that it is the actual gateway.
When you edit the interface itself, the dropdown list of gateways shows you all the gateways which apply to the interface, and you pick one.
I guess allowing you to predefine multiple possible gateways for an interface lets you have them setup ready to use and you can easily swap around between them, someone must have had a use case for that, or it just fell out easily that way when coding the system. (since you have to be able to have IPv4 and IPv6 gateways…)

TDSL use pppoe in PPP log this interface is up since 03:00 and didn't have any problem. while the reload loop TDSL had a big upstrem and the interface quality was >400ms.

The default latency thresholds for apinger gateway monitoring are 200/500ms. When a WAN link is being saturated by upload and/or download then the ping latency is likely to go high, just because the ICMP packets get stuck in queues of traffic on the saturated link. Usually I don't want pfSense to declare the link down for stuff like this - the link is actually working at full capacity!
I increase the latency thresholds in System->Routing Gateways, Edit Gateway, Advanced to something high - e.g. 1000 to 1500ms or even higher. That would probably prevent this apparent gateway flapping in your situation.

I reverted to old behaviour and made this a system tunable.

@jimp:

It just means that the port didn't get rebuilt on the builders after that commit.

It should be updated in the next new snapshot.

Interesting, thank you  ;D

Latest snapshot is indeed dnsmasq 2.66 btw…..

I made a bug report for this (redmine #2984).

Yeah, I think we should create dedicated thread and test things out…
I˙m willing to cooperate fully to resolve this issue or bug if it trully exists...

They are still building out code to implement CoDel properly. Wait a few days, I'm sure it'll be half working soon enough. There are even a few commits that didn't make it into the latest snapshot (20130506-1654)

For reference: https://redmine.pfsense.org/projects/pfsense/activity?show_changesets=1&with_subprojects=0&with_subprojects=1

Oh yes..I see what you're saying now..ok.

Hi Phil..

Not this week, but the following week, I'll be trying to reproduce it…

Thanks, Jits.

Had the same thought. After a hard power-cycle it's up and running 2.1 and now the only issue is the avahi package wouldn't run. Looks like I was indeed running i386 before. I think had trouble initially installing the AMD64 version of 2.0 on this old intel P4

Thanks for the assist.

Hello Wallabybob, here is what I'm doing.

Interfaces->assign->vlans

Edit an existing vlan

Change the parent interface to a different physical interface and save.  The save takes place instantly, no applying.

Look at the Interface Assignments

Notice that the logical interface that was assigned to the vlan that I changed has been switched to the first available interface, which on my system is a physical interface, and not the correct choice.

If the correct action is to create a new vlan, then maybe there shouldn't be an option to change the interface when editing the vlan, to force the correct usage.  I do see that if I just created all new vlan's for the new interface, then went and changed all the logical interface assignments, and then moved the cable I could make the change sort of atomic.

I don't really see what difference it makes though.  The system does keep you from moving a vlan to a physical interface that already has that VLAN tag assigned, so changing the interface vs creating new seems like the same thing to me, other than if you are trying to make the change atomic.

It seems like there will then be no non tedious option for changing a vlan trunk port from one physical interface to another via the GUI.  It be great if there were selection boxes and a "move all selected vlan's to physical interface x" option, that would keep the correct logical interface assignments also.

Josh

@ermal:

Normally it should be easier for FreeBSD(netgraph/mpd5) to include this.
Since from my understanding this is just patching the ng_ppp and mpd5 to provide an option for this.

Have not read teh RFC yet if it requires the interface to bump to 1508 mtu or not since that is a more severe impact in general.

Interface MTU of 8 bytes higher than the PPP MTU is a must to allow for the PPPoE header. This means that for PPP MTUs higher than 1492 negotiated using RFC 4638, a jumbo capable network interface in jumbo mode is required. The PPP-Max-Payload MTU will have to be clamped at the lower of the value signalled from mpd5 and the interface MTU (less 8 bytes in the latter case).

All the RFC does is give the method to negotiate an maximum MTU in place of the usual PPPoE maximum of 1492. It's up to the PPP layer to make use of this negotiated maximum MTU to negotiate a PPP MTU above 1492, and the transport layer and network must be capable of operating at that MTU.

@jimp:

Not that it directly helps, but baby jumbo frame support was also just added in the last OpenBSD release, I remember seeing it in their announcement.

Both OpenBSD and NetBSD now have RFC 4638 support. As they don't use netgraph for PPPoE, the implementation cannot be directly ported to FreeBSD, though, as ermal says, adding support to FreeBSD shouldn't be too hard.

Connections supporting RFC 4638 are common in the UK. All BT Openreach provided VDSL2 and FTTP circuits support a 1500 byte PPP MTU. Almost every ISP using these circuits uses PPPoE - the notable exception is Sky, which uses DHCP (I forget which DHCP option is used for authentication).

All the VDSL2 modems and FTTP ONTs supplied by BT Openreach with these connections can support a 1500 byte PPP MTU. If BT Openreach decided to offer 'wires only' VDSL2, it will be up to the customer / ISP to select hardware with baby jumbo support.

There's a lot of pfSense users in the UK who could make use of this if it was available, assuming their pfSense box has a jumbo capable NIC.

The situation does clear up after a reboot, but comes back when I change the wan interface again.  I will file a bug report.
Josh

Applying the patch by hands on the last amd64 version worked fine…