Pfsense not registering DNS servers found by PPP
-
@jimp: this time I searched redmine ::)
The description for the commit " the system general DNS settings … would not work anymore when set to none" describes what I get with a WAN on ppp0. No dns servers are found. All is well if I manually enter dns servers under System: General Setup.
Happens up to most recent snap of 2.1 but was not so in 2.0.1.
Others here have written about umts/LTE modems without mentioning this issue, so I assume it is peculiar to my ISP. Anyone else?
(have edited subject to properly reflect the symptom)
-
Have you looked in your PPP log or system to see if the ISP gave you a DNS? If I recall correctly PPP leaves a hint in the system log if it was given a DNS (or two). I'm running with enhanced PPP logging so my log probably won't be helpful in showing you what to look for.
-
Yes dns is given, as shown by the ppp logs. The problem is pfsense does not know about the dns servers, though it correctly sets the ip address, gateway from the apn.
-
Hi - i was curious and can confirm this behaviour.
I removed my manually configured DNS Servers and reconnected:Like in ryates case, IPCP sends the Information:
May 18 14:35:35 ppp: [wan] IPADDR 109.41.249.96 May 18 14:35:35 ppp: [wan] PRIDNS 139.7.30.126 May 18 14:35:35 ppp: [wan] SECDNS 139.7.30.125 May 18 14:35:35 ppp: [wan] IPCP: state change Ack-Sent --> Opened May 18 14:35:35 ppp: [wan] IPCP: LayerUp May 18 14:35:35 ppp: [wan] 109.41.249.96 -> 10.64.64.0 May 18 14:35:36 ppp: [wan] IFACE: Up event May 18 14:35:36 ppp: [wan] IFACE: Rename interface ng1 to ppp0But they wont be added automagically….
...cause mpd5 calls /usr/local/sbin/ppp-linkup different then the current version expects it.
This was bugging me too so i took a look at it and...#!/bin/sh # let the configuration system know that the ip has changed. /bin/echo $4 > /tmp/$1_router /bin/echo $3 > /tmp/$1_ip /usr/bin/touch /tmp/$1up ALLOWOVERRIDE=`/usr/bin/grep -c dnsallowoverride /conf/config.xml` if [ $ALLOWOVERRIDE -gt 0 ]; then # write nameservers to file dns1_adr=`/bin/echo $6 | /usr/bin/cut -c6-20` dns2_adr=`/bin/echo $7 | /usr/bin/cut -c6-20` if [ $dns1_adr != "" ]; then echo $dns1_adr >> /var/etc/nameserver_$1 /sbin/route change $dns_adr1 $4 fi if [ $dns2_adr != "" ]; then echo $dns2_adr >> /var/etc/nameserver_$1 /sbin/route change $dns_adr2 $4 fi /usr/local/sbin/pfSctl -c 'service reload dns' /bin/sleep 1…this one works on my installation :)
hanD Tho :
-
..this one is a small fix and will work for the plain ppp dialup case.
It might be relevant for other cases too (eg pppoe). -
the commit referenced above is unrelated to this issue. We recently updated the ppp-linkup script for IPv6, maybe that's what is biting it
-
I think this might be the case - it seems that mpd calls ppp-linkup with param 6 = dns1 [space] address.
Should i try to commit the script ? -
apart from the change where we inspect if $3 or $4 is a ipv4 or IPv6 address it shouldn't matter.
It could be that you are sent ipv6 config, which makes it run twice which in turn clobbers the existing nameservers. Let me adjust that.
-
apart from the change where we inspect if $3 or $4 is a ipv4 or IPv6 address it shouldn't matter.
It could be that you are sent ipv6 config, which makes it run twice which in turn clobbers the existing nameservers. Let me adjust that.
Did this get done? There is not a ticket for this on redmine and snap built on Fri May 25 06:13:59 EDT 2012 still has the issue.
rgrds
-
Please file a ticket in redmine, I forgot.
-
-
Can you test the new ppp-linkup script in /usr/local/sbin?
Let me know if that works for you
-
Sorry, it does not work. I will post the PPP log on Redmine rather than here. The changes appear to disable my modem as the log indicates it is unreceptive to AT commands. Simply copying back the previous version of the script and entering the DNS info restores the connection.
-
I can connect with the latest snapshot -
(removed all entries in /var/etc/resolv.conf and reconnected)I cant think of a case where the ppp linkup script would normally affect the chatscript.. mmh.
My 3g sometimes hangs and wont respond to ats anymore (stupid littl :)
I have to un and replug it and reload the vm to get it working again.
but didnt look for your ppp log yet..Ah - its a bit clearer
May 28 21:21:19 ppp: [wan] SECDNS 0.0.0.0ppp-linkup scriptmaybe you could (try to) connect and post the contents of your /var/etc/mpd_wan.conf ? (if wan is your inet port)
-
Yah! I got a different response from the latest snap that includes the modified ppp-linkup script than I did when I simply copied in just the script and rebooted. BUT, for now unlike you I am not getting a connection unless I manually enter the dns info, so am investigating…....
-
I cannot see anything wonky in the attached file….
@ ThorstenK: I have the same problem with the umts/lte connections, they can be very touchy and fall-over without recovering. I must say tho', that 2.1 beta seems to produce more fall-overs than did 2.0.1 but I cannot of course discount that the ISP lately had more issues. If you read the redmine report you will see that the modem currently will not survive a disconnect/reconnect and gives the AT error. I never saw that one under 2.0.1...
-
it's more likely to be caused by a mpd.script error.
I must have broken it somewhere.
-
@databeestje: Please shout if you want any logs, debug my end.
BTW, were you asking us to post our modem details (/dev/cuaU0.x etc) in this thread http://forum.pfsense.org/index.php/topic,49667.0.html ?
-
See http://forum.pfsense.org/index.php/topic,50548.msg269527.html#msg269527 and https://redmine.pfsense.org/issues/2458#note-8
Someone please confirm fix - I went off 2.1 as the modem lockups took down the firewall with regularity.
-
Yeah, I wanted some hardware details about the modems, mostly manufacturers etc.
The PPP fix works for me on 3G and PPPoE. Which I think covers it. I can reliably lockup the 3G connection on a ZTE modem though, I blame the ZTE modem for that mainly. Not having any issues with Huawei modems, they stay online for weeks. My 3G signal here is so-so. So every now and again it drops, the huawei just drops out of data modem with no-carrier and on it goes.
The ZTE device does not, which means we can't talk AT to it unless we reset the device, which can only be done over the application port which is just wrong.