MLPPP problem (Solved or good as..)
-
I have an MLPPP setup that seems to work fairly well on the LAN. XP machines seemed to have issues at first but WIn7 machines worked immediately…
Where Im having trouble is during automatic firmware updates every time or packages intermittently... When I try to run them it seems to lock up the webgui and make it unreachable for several hours.
The firewall continues to operate just fine... Im curious if the mrru or mru numbers on my ppp log look ok to anyone familiar...
Mar 11 20:21:58 ppp: [wan_link1] ENDPOINTDISC [Magic] bc 19 36 be 30 80 37 be
Mar 11 20:21:58 ppp: [wan] IPCP: rec'd Configure Request #1 (Req-Sent)
Mar 11 20:21:58 ppp: [wan] COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
Mar 11 20:21:58 ppp: [wan] IPADDR 12.34.56.1
Mar 11 20:21:58 ppp: [wan] 12.34.56.1 is OK
Mar 11 20:21:58 ppp: [wan] IPCP: SendConfigAck #1
Mar 11 20:21:58 ppp: [wan] COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
Mar 11 20:21:58 ppp: [wan] IPADDR 12.34.56.1
Mar 11 20:21:58 ppp: [wan] IPCP: state change Req-Sent –> Ack-Sent
Mar 11 20:21:58 ppp: [wan] IPCP: rec'd Configure Nak #1 (Ack-Sent)
Mar 11 20:21:58 ppp: [wan] IPADDR 12.34.56.109
Mar 11 20:21:58 ppp: [wan] 12.34.56.109 is OK
Mar 11 20:21:58 ppp: [wan] IPCP: SendConfigReq #2
Mar 11 20:21:58 ppp: [wan] IPADDR 12.34.56.109
Mar 11 20:21:58 ppp: [wan] COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
Mar 11 20:21:58 ppp: [wan] IPCP: rec'd Configure Ack #2 (Ack-Sent)
Mar 11 20:21:58 ppp: [wan] IPADDR 12.34.56.109
Mar 11 20:21:58 ppp: [wan] COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
Mar 11 20:21:58 ppp: [wan] IPCP: state change Ack-Sent –> Opened
Mar 11 20:21:58 ppp: [wan] IPCP: LayerUp
Mar 11 20:21:58 ppp: [wan] 12.34.56.109 -> 12.34.56.1
Mar 11 20:21:59 ppp: [wan] IFACE: Up event
Mar 11 20:21:59 ppp: [wan_link1] LCP: rec'd Configure Ack #2 (Req-Sent)
Mar 11 20:21:59 ppp: [wan_link1] PROTOCOMP
Mar 11 20:21:59 ppp: [wan_link1] MRU 1492
Mar 11 20:21:59 ppp: [wan_link1] MAGICNUM 0bb75a2c
Mar 11 20:21:59 ppp: [wan_link1] MP MRRU 2048
Mar 11 20:21:59 ppp: [wan_link1] ENDPOINTDISC [Magic] bc 19 36 be 30 80 37 be
Mar 11 20:21:59 ppp: [wan_link1] LCP: state change Req-Sent –> Ack-Rcvd
Mar 11 20:22:00 ppp: [wan_link1] LCP: rec'd Configure Request #2 (Ack-Rcvd)
Mar 11 20:22:00 ppp: [wan_link1] MRU 1492
Mar 11 20:22:00 ppp: [wan_link1] AUTHPROTO PAP
Mar 11 20:22:00 ppp: [wan_link1] MAGICNUM 2f9dc8cb
Mar 11 20:22:00 ppp: [wan_link1] MP MRRU 1524
Mar 11 20:22:00 ppp: [wan_link1] ENDPOINTDISC [LOCAL] 52 34 5f 37 32 30 36
Mar 11 20:22:00 ppp: [wan_link1] LCP: SendConfigAck #2
Mar 11 20:22:00 ppp: [wan_link1] MRU 1492
Mar 11 20:22:00 ppp: [wan_link1] AUTHPROTO PAP
Mar 11 20:22:00 ppp: [wan_link1] MAGICNUM 2f9dc8cb
Mar 11 20:22:00 ppp: [wan_link1] MP MRRU 1524
Mar 11 20:22:00 ppp: [wan_link1] ENDPOINTDISC [LOCAL] 52 34 5f 37 32 30 36
Mar 11 20:22:00 ppp: [wan_link1] LCP: state change Ack-Rcvd –> Opened
Mar 11 20:22:00 ppp: [wan_link1] LCP: auth: peer wants PAP, I want nothing
Mar 11 20:22:00 ppp: [wan_link1] PAP: using authname ":)"
Mar 11 20:22:00 ppp: [wan_link1] PAP: sending REQUEST #1 len: 21
Mar 11 20:22:00 ppp: [wan_link1] LCP: LayerUp
Mar 11 20:22:00 ppp: [wan_link1] PAP: rec'd ACK #1 len: 5
Mar 11 20:22:00 ppp: [wan_link1] LCP: authorization successful
Mar 11 20:22:00 ppp: [wan_link1] Link: Join bundle "wan"
Mar 11 20:22:00 ppp: [wan] Bundle: Status update: up 2 links, total bandwidth 128000 bpsOtherwise this is a great way to solve my lack of decent speed at this lo-cal….
-
After getting some time and working on this for a while Ive been able to fix my XP issues by forcing a couple of settings… MTU and MRU... Seems my ISP may need some tweaks.
Now I can download firmware updates to any computer connected to my lan behind this pfsense box...
However I can not get the firmware update to download on this box using the auto option from the gui...
Packages intermittently work. Sometimes they stall and a second or third try will finally work. Im using widescreen and file mgr.
On the latest 2.0rc as of this posting. Updates worked before going with mlppp setup.
Does the box itself make use of the mlppp pair or is it possible that only one link is used and I still have an mtu issue?
Finally getting a little bit better speeds to this site make any extra steps I have to go through worth it.But it would be nice to understand whats going on in my case...
;)
-
Getting this right now while trying to visit package page…
"Unable to communicate with www.pfsense.com. Please verify DNS and interface configuration, and that pfSense has functional Internet connectivity."
No problems with accessing the box via its wan port remotely right now... Nor the lan behind it...
-
After an update to the (2.0-RC1 (i386)built on Fri Mar 18 21:32:32 EDT 2011) firmware Im getting…
Unable to retrieve package info from www.pfsense.com. Cached data will be used.
I did not have any issues reinstalling packages from this page…
Almost like dns is only working for part of my install...
Weird.
-
Using speedguides TCPoptimizer…
Pinging [65.249.x.x] with 1500 bytes -> ..fragmented
Pinging [65.249.x.x] with 750 bytes ->bytes=750 time=69ms TTL=57
Pinging [65.249.x.x] with 1125 bytes ->bytes=1125 time=75ms TTL=57
Pinging [65.249.x.x] with 1312 bytes ->bytes=1312 time=78ms TTL=57
Pinging [65.249.x.x] with 1406 bytes ->bytes=1406 time=99ms TTL=57
Pinging [65.249.x.x] with 1453 bytes ->bytes=1453 time=83ms TTL=57
Pinging [65.249.x.x] with 1476 bytes -> ..fragmented
Pinging [65.249.x.x] with 1464 bytes ->bytes=1464 time=86ms TTL=57
Pinging [65.249.x.x] with 1470 bytes ->Request Timed Out
The host you've chosen does not accept ICMP Pings, please chose a different one.If mrru is >1500 then why am I seeing this pinging the box? The box seems to lock up once a few fragmented packets come along thus seeming to cause my issues…
Anyone got any ideas?
-
From where are you pinging?
For mlppp i suggest you disable the scrub settings on the advanced section or put a value there equal to the mtu settings.
Though disabling scrub is best imo. -
@ermal:
From where are you pinging?
For mlppp i suggest you disable the scrub settings on the advanced section or put a value there equal to the mtu settings.
Though disabling scrub is best imo.Im pinging into the wan side of my mlppp connected box from my home account.
Trying the scrub disable now…
Thanks!
-
Fetching file…
looking up snapshots.pfsense.org
connecting to snapshots.pfsense.org:80
requesting http://snapshots.pfsense.org/FreeBSD_RELENG_8_1/i386/pfSense_HEAD/.updaters//latest.tgz
remote size / mtime: 90358054 / 1301005080
/root/firmware.tgz 0% of 86 MB 0 Bps
/root/firmware.tgz 0% of 86 MB 783 Bps 32h09m/root/firmware.tgz 0% of 86 MB 1792 Bps 13h57m
I can go and successfully get the same file on a machine on the lan port of this box... I think tomorrow I am going to wipe the drive and start over to see if the problem still happens...
-
Started from scratch today… blew the drive up and started with a fresh slate...
Now running 2.0-RC1 (i386)
built on Mon Mar 28 16:37:49 EDT 2011Running an ADSL pair from my ISP.
With 2 links active...
Pinging [65.249.x.x] with 1500 bytes -> ..fragmented
Pinging [65.249.x.x] with 750 bytes ->bytes=750 time=68ms TTL=57
Pinging [65.249.x.x] with 1125 bytes ->bytes=1125 time=91ms TTL=57
Pinging [65.249.x.x] with 1312 bytes ->bytes=1312 time=74ms TTL=57
Pinging [65.249.x.x] with 1406 bytes ->bytes=1406 time=82ms TTL=57
Pinging [65.249.x.x] with 1453 bytes ->bytes=1453 time=90ms TTL=57
Pinging [65.249.x.x] with 1476 bytes -> ..fragmented
Pinging [65.249.x.x] with 1464 bytes ->Request Timed Out
The host you've chosen does not accept ICMP Pings, please chose a different one.With only one of the links active. ( does not matter which one.)
Pinging [65.249.x.x] with 1500 bytes -> ..fragmented
Pinging [65.249.x.x] with 750 bytes ->bytes=750 time=53ms TTL=57
Pinging [65.249.x.x] with 1125 bytes ->bytes=1125 time=59ms TTL=57
Pinging [65.249.x.x] with 1312 bytes ->bytes=1312 time=63ms TTL=57
Pinging [65.249.x.x] with 1406 bytes ->bytes=1406 time=64ms TTL=57
Pinging [65.249.x.x] with 1453 bytes ->bytes=1453 time=95ms TTL=57
Pinging [65.249.x.x] with 1476 bytes -> ..fragmented
Pinging [65.249.x.x] with 1464 bytes ->bytes=1464 time=67ms TTL=57
Pinging [65.249.x.x] with 1470 bytes ->Unknown error: 0
Pinging [65.249.x.x] with 1469 bytes -> ..fragmented
Pinging [65.249.x.x] with 1466 bytes -> ..fragmented
Pinging [65.249.x.x] with 1465 bytes -> ..fragmented
The largest possible non-fragmented packet is 1464 (1492 - 28 ICMP & IP headers).
You can set your MTU to 1492Looks like either the ISP side or my side quits responding with the pair active after too many fragmented packets. But not with the single link.
I can probably safely assume that no one else is having this issue due to the lack of others chiming in with the same problem. My next chore will be to work with the ISP.
-
As a test I set my MTU at 1440 my WAN interface page, and at /interfaces_ppps_edit.php for each physical interface….
Running ifconfig I still show all the interfaces have an mtu of 1500. Should they not show 1440 on the wan side now?
vr0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
options=82808 <vlan_mtu,wol_ucast,wol_magic,linkstate>ether 1c:bd:b9:83:e5:3c
inet6 fe80::1ebd:b9ff:fe83:e53c%vr0 prefixlen 64 scopeid 0x2
nd6 options=3 <performnud,accept_rtadv>media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
vr1: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
options=82808 <vlan_mtu,wol_ucast,wol_magic,linkstate>ether 00:24:01:00:0c:0b
inet6 fe80::224:1ff:fe00:c0b%vr1 prefixlen 64 scopeid 0x3
nd6 options=3 <performnud,accept_rtadv>media: Ethernet autoselect (100baseTX <full-duplex>)
status: activepppoe0: flags=88d1 <up,pointopoint,running,noarp,simplex,multicast>metric 0 mtu 1500
inet 65.249.x.x --> 65.249.x.x netmask 0xffffffff
inet6 fe80::209:5bff:fe8f:1b71%pppoe0 prefixlen 64 scopeid 0xa
nd6 options=3<performnud,accept_rtadv></performnud,accept_rtadv></up,pointopoint,running,noarp,simplex,multicast></full-duplex></performnud,accept_rtadv></vlan_mtu,wol_ucast,wol_magic,linkstate></up,broadcast,running,simplex,multicast></full-duplex></performnud,accept_rtadv></vlan_mtu,wol_ucast,wol_magic,linkstate></up,broadcast,running,simplex,multicast> -
Looks like rsingh was having similar issues with later builds possibly…
http://forum.pfsense.org/index.php/topic,23094.45.html
-
I had an appointment and sat down with the technical department of my ISP today.
Tech noticed the setting "ppp multilink fragment disable" was set on their end and not on my router…
So question would be whether or not this should be set or not... But since it was easier to have them turn it off I asked them to.
Now my mlppp connection is behaving correctly. ;D :) ( Insert partying smiley here. )
So question to the dev's... Could this setting be included on the advanced section of the ppp's page for others that may be having issues to try??
