headers
JC Janos | 15 Nov 03:43
Picon

pppoe config connects, but can't ping *past* gateway. something wrong with my routes?

Hi,

I'm setting up my 1st linux router/firewall for my office. I'm
connecting to the net via ATT DSL using PPPoE.  It's connected, but
something's wrong with my config (routing?) as I can't seem to ping
past my gateway.

I'm running a headless Opensuse 11.0 box,

uname -a
  Linux router 2.6.25.18-0.2-default #1 SMP 2008-10-21 16:30:26 +0200
i686 i686 i386 GNU/Linux

pppd --version
	pppd version 2.4.4

ATT have allocated a Static block x.x.x.144/29 to me.

From the info I've been able to find online, I've set up ppp config as follows,

/etc/ppp/peers/att
	plugin /usr/lib/pppd/2.4.4/rp-pppoe.so
	eth0
	user "username <at> att.net"

/etc/ppp/pap-secrets
	"username <at> att.net" *  "password" *

/etc/ppp/options
	debug
(Continue reading)

Permalink | Reply | 3 comments |
headers
Gilles Espinasse | 15 Nov 08:30
Picon
Favicon

Re: pppoe config connects, but can't ping *past* gateway. something wrong with my routes?


----- Original Message ----- 
From: "JC Janos" <jcjanos245 <at> gmail.com>
To: <linux-ppp <at> vger.kernel.org>
Sent: Saturday, November 15, 2008 3:43 AM
Subject: pppoe config connects, but can't ping *past* gateway. something
wrong with my routes?

> Hi,
>
> I'm setting up my 1st linux router/firewall for my office. I'm
> connecting to the net via ATT DSL using PPPoE.  It's connected, but
> something's wrong with my config (routing?) as I can't seem to ping
> past my gateway.
>
...
> /etc/ppp/options
> debug
> ktune
> logfile  /var/log/ppp.log
>
> noauth
> hide-password
> noipdefault
> persist
> holdoff 30
>
> noaccomp
> nobsdcomp
> noccp
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Carlson | 15 Nov 15:35

Re: pppoe config connects, but can't ping *past* gateway. something wrong with my routes?

JC Janos writes:
> /etc/ppp/ip-up.local
> 	echo /sbin/ip route list | awk '/^default / { print $3 }' > /etc/default-route
> 	/sbin/route del default
> 	/sbin/route add default netmask 255.255.255.248 gw x.x.x.150
[...]
> and to my gateway,
> 
> 	ping -c 1 99.164.169.50
> 		PING 99.164.169.50 (99.164.169.50) 56(84) bytes of data.
> 		64 bytes from 99.164.169.50: icmp_seq=1 ttl=255 time=11.9 ms

It looks like your routes are misconfigured.  Your default route in
this case should point to the other end of this link -- 99.164.169.50
as you've shown -- and not to one of your own local addresses.  By
using a local address, you've basically told the kernel to drop all
your packets, and it's just doing what you've asked it to do.

As another poster suggested, you should use the "defaultroute" option
instead of this ip-up hackery.  If you really do need all of this
complex manual configuration in the ip-up script, then consider using
the $IPREMOTE environment variable or $5 in /etc/ppp/ip-up.  (I'm not
sure how Linux handles the command line arguments for that script, but
pppd itself passes the remote address as $5 when it invokes
/etc/ppp/ip-up.)

--

-- 
James Carlson         42.703N 71.076W         <carlsonj <at> workingcode.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jar | 16 Nov 17:20
Picon
Picon

Re: ppp0 and it's txqueuelen with HSDPA gsm modems

Lie Arne wrote:
>> What would be "optimal" value for ppp0 device's txqueuelen, 
>> when it is used with HSDPA gsm modem for link which downlink 
>> speed is 1Mbit/s and uplink speed is 384kbit/s and ping 
>> ~80..100 ms? Is the default value 3 just OK?
>>
>> --
>> Best Regards, Jar
> 
> I would suggest using normal TCP calculation, i.e. that you dimension
> the txqueue size after the "BDP rule": bandwidth x delay product. Using
> your outbound numbers this is:
> 1,000,000 x 0.1 = 100,000 bits = 12,500 bytes. Assuming 1500 byte
> packets, this is txqueue = 12,500 / 1500 = 8.3 packets. So you could try
> txqueue size in the region 8-10, this should prevent queue starvation at
> packet drop events caused by traffic overload, even if you only have one
> single TCP flow.

OK, thanks. But is txqueuelen for transmit data only and then the 
downlink value (384kbit/s) should be used in the calculation? With 
384kbit/s the txqueuelen would be 3.2 which is quite same as ppp0 default 3.

--

-- 
Best Regards, Jar
--
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Carlson | 18 Nov 17:53

Re: switching to command mode when using a PPPD with a gprs modem

Paul De La Rosa writes:
> Is there a way with pppd to send the '+++' command to temporarily switch
> out of data mode into command mode. I'm using a Siemens tc63 module and
> I need to check signal strength every now and then but I was trying to
> avoid bringing down the whole ppp0 interface to do that check. I tried
> spawning pppd as a child process using the same file descriptor as the
> parent so the parent could send the mode switch and signal strength
> commands but it seems that pppd is reading the data that is returned
> before the parent got it.

This is something that's been discussed a few times.  In order to do
it "right," you'd need to modify the PPP kernel driver to do this
work, so that you don't accidentally stomp too much on packets in
flight.

A slightly better way to do this (rather than the Hayes TIES signal)
is to use the enter-command-mode-on-DTR-drop configuration for the
modem, and then use that to switch back and forth reliably between
data and command mode.  It still requires driver involvement, and it
also requires explicitly doing ATH to hang up (rather than just
closing the device), but it's much more reliable.

Better still is to get a commercial-grade modem that has a separate
performance monitoring interface.  That's what we ended up doing when
I was at Bay Networks; all of the other in-band methods of signaling
are mere hackery in comparison.

--

-- 
James Carlson         42.703N 71.076W         <carlsonj <at> workingcode.com>
--
(Continue reading)

Permalink | Reply | 0 comments |
headers
周佳政 | 19 Nov 05:55
Picon

PHP購物車資料庫網站專案

山鉧科技網頁設計

＊我們的宗旨：客戶的每ㄧ件小事情，都是山鉧的大事情

◆我們在推出企業形象網站包含前台網頁美工+後台管理程式

＝＝限時限量專案價 只要$29,900

↖(在送ㄧ年100MB不限流量網站空間)

↖我們做的不只是網站，而是您企業的入口

㊣ㄧ個好的企業網站資料即時更新的速度是很重要的

↖企業ｅ化的高品質團隊，打造您的網路門面

∴選擇山鉧成就您的夢想

～～～～～～～～～～～～～～～～～～～～～～～～～～
PS: 線上購物網站我們還可提供刷卡機制，
　　與線上列印帳單全省超商+郵局繳費......等金流服務機制
～～～～～～～～～～～～～～～～～～～～～～～～～～

歡迎來電洽詢黃專員（Sam）：0980119812 / 0938764395

～～～～～～～～～～～～～～～～～～～～～～～～～～
本公司另外提供關鍵字SEO排序服務
保證將您的網站在Yx / Gx ...排在第一頁
　　　　　　　　　　　　　　　　　　 歡迎來電詢問!!!
～～～～～～～～～～～～～～～～～～～～～～～～～～
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nicholas Hickman | 19 Nov 15:10
Favicon
Gravatar

(unknown)

Unsubscribe linux-ppp 
--
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
tony.chamberlain | 26 Nov 14:47

pptp failure

I have the same pptp configuration stuff on two Linux boxes.
Box A is 2.6.9-78.0.5.ELsmp #1 and Box B is 2.6.9-55.ELsmp #1 SMP.
Up until just a few days ago pptp from both boxes worked fine.

Options: MPPE and refuse EAP.  The other 2 encryption boxes are not checked.
         In miscellaneous I have debug turned on.

Box B shows this from debug:
  sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x354ce8ff> <pcomp> <accomp>]
  rcvd [LCP ConfReq id=0x1 <auth chap MS-v2> <mru 1460> <magic 0x99302d60>]
  (then some more sent and receiveds)

Box A just show repeat:
  sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xe58c245e> <pcomp> <accomp>]
  sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xe58c245e> <pcomp> <accomp>]
  Script pptp X.X.X.X --nolaunchpppd  finished (pid 18300), status = 0x0
  Modem hangup
  Connection terminated.
(I Xed out the actual VPN IP address which is the same as Box B).

So for some reason, Box A is not getting a response back.  I see it is 
a different magic number.  Could that have anything to do with it?  After
a short time it gets a SIGUSR:
   pptpconfig: pppd process terminated by signal 16 (failed)
   pptpconfig: SIGUSR1

Any idea what is happening?  I did recently install cisco vpn client
on Box A, but pptp was working after to that.

--
(Continue reading)

Permalink | Reply | 1 comment |
headers
James Cameron | 26 Nov 23:06
Picon
Favicon

Re: pptp failure

On Wed, Nov 26, 2008 at 01:47:44PM +0000, tony.chamberlain <at> lemko.com wrote:
> Box B shows this from debug:
>   sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x354ce8ff> <pcomp> <accomp>]
>   rcvd [LCP ConfReq id=0x1 <auth chap MS-v2> <mru 1460> <magic 0x99302d60>]
>   (then some more sent and receiveds)

Looks normal.  Nothing unusual.  I presume Box B is working fine?  You
didn't explicitly say.

> Box A just show repeat:
>   sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xe58c245e> <pcomp> <accomp>]
>   sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xe58c245e> <pcomp> <accomp>]
>   Script pptp X.X.X.X --nolaunchpppd  finished (pid 18300), status = 0x0
>   Modem hangup
>   Connection terminated.
> (I Xed out the actual VPN IP address which is the same as Box B).
> 
> So for some reason, Box A is not getting a response back.

This shows pppd is not receiving any data from the peer.  Without data,
pppd will not succeed.

Diagnose this further by verifying the arrival of GRE packets, protocol
47, on the network interface that the TCP port 1723 connection should
have established on.  If no packets arrive, then the problem is outside
your host.

> I see it is a different magic number.  Could that have anything to do
> with it?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Cyrill Gorcunov | 27 Nov 21:12
Picon
Gravatar

[PATCH] net: ppp_asynctty_ioctl - remove dead code

ap already checked to be not null. remove useless checks.

Signed-off-by: Cyrill Gorcunov <gorcunov <at> gmail.com>
---

Please review

diff --git a/drivers/net/ppp_async.c b/drivers/net/ppp_async.c
index 451bdb5..6567fab 100644
--- a/drivers/net/ppp_async.c
+++ b/drivers/net/ppp_async.c
@@ -293,9 +293,6 @@ ppp_asynctty_ioctl(struct tty_struct *tty, struct file *file,
 	err = -EFAULT;
 	switch (cmd) {
 	case PPPIOCGCHAN:
-		err = -ENXIO;
-		if (!ap)
-			break;
 		err = -EFAULT;
 		if (put_user(ppp_channel_index(&ap->chan), p))
 			break;
@@ -303,9 +300,6 @@ ppp_asynctty_ioctl(struct tty_struct *tty, struct file *file,
 		break;

 	case PPPIOCGUNIT:
-		err = -ENXIO;
-		if (!ap)
-			break;
 		err = -EFAULT;
 		if (put_user(ppp_unit_number(&ap->chan), p))
(Continue reading)

Permalink | Reply | 0 comments |

Gmane