Closed bigjohns97 closed 3 years ago
Just to be clear you can't build that for i386 and use it in an armv7 system, such as the SG-3100.
Just to be clear you can't build that for i386 and use it in an armv7 system, such as the SG-3100.
Don't I know it. I forgot the Netgate platform was based on ARM until I was further along.
I solved my problem by moving to static IP's - an option available with fiber to the home for a small fee.
It's not a perfect solution because it requires the ISP router be in front of pfsense, but it does solve the problem of allowing inbound connections directly to pfsense without using the wpa_supplicant.
--Edit-- I left a ticket to add this patch to Netgate appliances open
Just to be clear you can't build that for i386 and use it in an armv7 system, such as the SG-3100.
Don't I know it. I forgot the Netgate platform was based on ARM until I was further along.
I solved my problem by moving to static IP's - an option available with fiber to the home for a small fee.
It's not a perfect solution because it requires the ISP router be in front of pfsense, but it does solve the problem of allowing inbound connections directly to pfsense without using the wpa_supplicant.
--Edit-- I left a ticket to add this patch to Netgate appliances open
FYI, even using the block of static IPs from AT&T, it still suffers the same issues as IP pass through for the WAN IP. All the connections still go through the state table on the RG. I have the block of 5 IPs and I use that with the netgraph bypass, planning to move to the wpa supplicant bypass once this issue is cleared up on pfsense’s side.
The original issue, wpa_supplicant using 100% CPU, is resolved in 2.5.2. pfSense 2.5.2 is released today and I've tested and confirmed it.
I believe this issue can be closed now (thankfully!). Thanks to everyone who helped test the fix.
Confirmed as well.
Does anyone have a link to the ng_etf.ko file? I am on mobile internet and unable to download FreeBSD. I upgraded from 2.4.5 to 2.5.2 and run into the error
KLD ng_etf.ko: depends on kernel - not available or version mismatch
The module is included in pfSense 2.5.2, you don't need to load it:
[2.5.2-RELEASE][admin@t70.stevew.lan]/root: kldstat -v | grep ng_etf
555 ng_etf
This is what I'm getting after upgrading, but doing kldstat -v | grep ng_etf once the system is booted does give me the same results
Any ideas what the issues could be? I installed pfatt a long time ago from the old repo, which had us manually copy ng_etf
This is my pfatt file config, if that helps
#!/bin/sh
set -e
ONT_IF='igb2'
RG_IF='igb0'
RG_ETHER_ADDR='REDACTED'
OPNSENSE='no'
LOG=/var/log/pfatt.log
getTimestamp(){
echo `date "+%Y-%m-%d %H:%M:%S :: [pfatt.sh] ::"`
}
{
echo "$(getTimestamp) pfSense + AT&T U-verse Residential Gateway for true bridge mode"
echo "$(getTimestamp) Configuration: "
echo "$(getTimestamp) ONT_IF: $ONT_IF"
echo "$(getTimestamp) RG_IF: $RG_IF"
echo "$(getTimestamp) RG_ETHER_ADDR: $RG_ETHER_ADDR"
echo "$(getTimestamp) OPNSENSE: $OPNSENSE"
echo -n "$(getTimestamp) loading netgraph kernel modules... "
/sbin/kldload -nq ng_etf
echo "OK!"
if [ ${OPNSENSE} != 'yes' ]; then
echo -n "$(getTimestamp) attaching interfaces to ng_ether... "
/usr/local/bin/php -r "pfSense_ngctl_attach('.', '$ONT_IF');"
/usr/local/bin/php -r "pfSense_ngctl_attach('.', '$RG_IF');"
echo "OK!"
fi
echo "$(getTimestamp) building netgraph nodes..."
echo -n "$(getTimestamp) creating ng_one2many... "
/usr/sbin/ngctl mkpeer $ONT_IF: one2many lower one
/usr/sbin/ngctl name $ONT_IF:lower o2m
echo "OK!"
echo -n "$(getTimestamp) creating vlan node and interface... "
/usr/sbin/ngctl mkpeer o2m: vlan many0 downstream
/usr/sbin/ngctl name o2m:many0 vlan0
/usr/sbin/ngctl mkpeer vlan0: eiface vlan0 ether
/usr/sbin/ngctl msg vlan0: 'addfilter { vlan=0 hook="vlan0" }'
/usr/sbin/ngctl msg ngeth0: set $RG_ETHER_ADDR
echo "OK!"
echo -n "$(getTimestamp) defining etf for $ONT_IF (ONT)... "
/usr/sbin/ngctl mkpeer o2m: etf many1 downstream
/usr/sbin/ngctl name o2m:many1 waneapfilter
/usr/sbin/ngctl connect waneapfilter: $ONT_IF: nomatch upper
echo "OK!"
echo -n "$(getTimestamp) defining etf for $RG_IF (RG)... "
/usr/sbin/ngctl mkpeer $RG_IF: etf lower downstream
/usr/sbin/ngctl name $RG_IF:lower laneapfilter
/usr/sbin/ngctl connect laneapfilter: $RG_IF: nomatch upper
echo "OK!"
echo -n "$(getTimestamp) bridging etf for $ONT_IF <-> $RG_IF... "
/usr/sbin/ngctl connect waneapfilter: laneapfilter: eapout eapout
echo "OK!"
echo -n "$(getTimestamp) defining filters for EAP traffic... "
/usr/sbin/ngctl msg waneapfilter: 'setfilter { matchhook="eapout" ethertype=0x888e }'
/usr/sbin/ngctl msg laneapfilter: 'setfilter { matchhook="eapout" ethertype=0x888e }'
echo "OK!"
echo -n "$(getTimestamp) enabling one2many links... "
/usr/sbin/ngctl msg o2m: setconfig "{ xmitAlg=2 failAlg=1 enabledLinks=[ 1 1 ] }"
echo "OK!"
echo -n "$(getTimestamp) removing waneapfilter:nomatch hook... "
/usr/sbin/ngctl rmhook waneapfilter: nomatch
echo "OK!"
echo -n "$(getTimestamp) enabling $RG_IF interface... "
/sbin/ifconfig $RG_IF up
echo "OK!"
echo -n "$(getTimestamp) enabling $ONT_IF interface... "
/sbin/ifconfig $ONT_IF up
echo "OK!"
echo -n "$(getTimestamp) enabling promiscuous mode on $RG_IF... "
/sbin/ifconfig $RG_IF promisc
echo "OK!"
echo -n "$(getTimestamp) enabling promiscuous mode on $ONT_IF... "
/sbin/ifconfig $ONT_IF promisc
echo "OK!"
echo "$(getTimestamp) ngeth0 should now be available to configure as your pfSense WAN"
echo "$(getTimestamp) done!"
} >> $LOG
Okay I fixed it, I coped my interfaces and mac into the new pfatt.sh, and replaced the file in pfsense
Because you are incorrectly trying to load a module that was compiled against an old kernel. Remove it.
You are still running the 'Before 2.4.5' version of pfatt.sh. The current version does not try to load the module.
Recently tried out PfSense 2.5 to test out the new version of unbound which fixes some issues with PfBlockerNG and null blocking and the python module which provides client ip addresses of DNS requests when using null blocking and noticed that wpa_supplicant is using all of one core upon boot.
Killing the PID results in loss of WAN but starting it back up using just the wpa_supplicant command from the script seems to restore WAN connectivity and not eat up the CPU.
Not sure how to troubleshoot but this might be something to look at as the 2.5 branch seems to be getting close to release.