Bug 11470
Summary: | pppoe not working when acting as gateway. | ||
---|---|---|---|
Product: | Networking | Reporter: | Pierluigi (pigi) |
Component: | Other | Assignee: | networking_netfilter-iptables (networking_netfilter-iptables) |
Status: | CLOSED CODE_FIX | ||
Severity: | blocking | CC: | acme, jarkao2, networking_netfilter-iptables, pigi |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.26.3 | Subsystem: | |
Regression: | --- | Bisected commit-id: |
Description
Pierluigi
2008-08-31 09:59:09 UTC
ccing to acme@ghostprotocols.net as I made something wrong in first assigning. Sorry Reply-To: akpm@linux-foundation.org (switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Sun, 31 Aug 2008 09:59:12 -0700 (PDT) bugme-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=11470 > > Summary: pppoe not working when acting as gateway. > Product: Networking > Version: 2.5 > KernelVersion: 2.6.26.3 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Netfilter/Iptables > AssignedTo: networking_netfilter-iptables@kernel-bugs.osdl.org > ReportedBy: pigi@frumar.it > CC: networking_netfilter-iptables@kernel-bugs.osdl.org > > > Latest working kernel version: 2.6.21.7 > Earliest failing kernel version: 2.6.22 > Distribution: Slackware > Hardware Environment: Ibm Thinkpad T23 Intel(R) Pentium(R) III Mobile CPU > 1133MHz > Software Environment: > Problem Description: > Packet are not handled back to clients, neither are see on ppp0 > > Steps to reproduce: > Just put a MASQUERADE rule in iptables, to NAT packects from client to > internet, with a FORWARD rule that allow the packects to be forwarded. Try to > ping or dig or telnet or whatever from the client and nothing happens. > > My configuration is : > > CLIENT ----> T23 -----> DSL-MODEM -----> INTERNET > > > Client = linux machine > T23 = linux machine with everything configure to act as a dsl router > On T23 I'm using vanilla kernel recompiled by myself, using the same config > that is working on 2.6.21.7 > pppoe binaries is : > root /usr/src >/usr/sbin/pppoe -V > Roaring Penguin PPPoE Version 3.8 > > > I have another linux machine on internet, that I have used to verify the > problem. > > When I run the ping from the client, on the router I can see the packet come > in > from the eth0 and leaving natted from the ppp0. On the internet machine I see > the icmp packet ( or whatever packet I send ) coming in, and the reply going > out to the router machine. > This packet seems to be lost ( i can't see it on the router either on ppp > interface than on eth0 interface ), by using tcpdump (3.9.5). > If the communication is started from the router ( icmp, ssh, whatever ) > everything works well. > > Running the 2.6.21.7 but keeping the same configuration for kernel, iptables > and all, is seen on router and handled back to client. > Not working behavior is seen on 2.6.22+ to 2.6.26.3 > Working behavior is seen on 2.6.21.7- ( at last to 2.6.19.2 which was my > starting kernel ) > > At beginning I thought the problem was with iptables > root /usr/src >iptables -V > iptables v1.3.8 > but the strange thing is that I can't even see the reply packets on ppp0 > interface, while if the trouble was on iptables rules, then I should have > seen > the packet and then I should have seen it dropped somewhere. > Anyway I have put netfilters guys in CC just in case I'm wrong. > > Googling around I have seen others that have similar behavior and I have seen > that in 2.6.22 there is been a lot of change in pppoe area. > > Let me know if you need more informations. > > The 2.6.22 .config is: > ... Andrew Morton wrote:
> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
> On Sun, 31 Aug 2008 09:59:12 -0700 (PDT) bugme-daemon@bugzilla.kernel.org
> wrote:
>
>> http://bugzilla.kernel.org/show_bug.cgi?id=11470
>>
>> Summary: pppoe not working when acting as gateway.
>> Product: Networking
>> Version: 2.5
>> KernelVersion: 2.6.26.3
>> Platform: All
>> OS/Version: Linux
>> Tree: Mainline
>> Status: NEW
>> Severity: normal
>> Priority: P1
>> Component: Netfilter/Iptables
>> AssignedTo: networking_netfilter-iptables@kernel-bugs.osdl.org
>> ReportedBy: pigi@frumar.it
>> CC: networking_netfilter-iptables@kernel-bugs.osdl.org
>>
>>
>> Latest working kernel version: 2.6.21.7
>> Earliest failing kernel version: 2.6.22
>> Distribution: Slackware
>> Hardware Environment: Ibm Thinkpad T23 Intel(R) Pentium(R) III Mobile CPU
>> 1133MHz
>> Software Environment:
>> Problem Description:
>> Packet are not handled back to clients, neither are see on ppp0
>>
>> Steps to reproduce:
>> Just put a MASQUERADE rule in iptables, to NAT packects from client to
>> internet, with a FORWARD rule that allow the packects to be forwarded. Try
>> to
>> ping or dig or telnet or whatever from the client and nothing happens.
>>
>> My configuration is :
>>
>> CLIENT ----> T23 -----> DSL-MODEM -----> INTERNET
>>
>>
>> Client = linux machine
>> T23 = linux machine with everything configure to act as a dsl router
>> On T23 I'm using vanilla kernel recompiled by myself, using the same config
>> that is working on 2.6.21.7
>> pppoe binaries is :
>> root /usr/src >/usr/sbin/pppoe -V
>> Roaring Penguin PPPoE Version 3.8
>>
>>
>> I have another linux machine on internet, that I have used to verify the
>> problem.
>>
>> When I run the ping from the client, on the router I can see the packet come
>> in
>> from the eth0 and leaving natted from the ppp0. On the internet machine I
>> see
>> the icmp packet ( or whatever packet I send ) coming in, and the reply going
>> out to the router machine.
>> This packet seems to be lost ( i can't see it on the router either on ppp
>> interface than on eth0 interface ), by using tcpdump (3.9.5).
>> If the communication is started from the router ( icmp, ssh, whatever )
>> everything works well.
>>
>> Running the 2.6.21.7 but keeping the same configuration for kernel, iptables
>> and all, is seen on router and handled back to client.
>> Not working behavior is seen on 2.6.22+ to 2.6.26.3
>> Working behavior is seen on 2.6.21.7- ( at last to 2.6.19.2 which was my
>> starting kernel )
>>
>> At beginning I thought the problem was with iptables
>> root /usr/src >iptables -V
>> iptables v1.3.8
>> but the strange thing is that I can't even see the reply packets on ppp0
>> interface, while if the trouble was on iptables rules, then I should have
>> seen
>> the packet and then I should have seen it dropped somewhere.
>> Anyway I have put netfilters guys in CC just in case I'm wrong.
>>
>> Googling around I have seen others that have similar behavior and I have
>> seen
>> that in 2.6.22 there is been a lot of change in pppoe area.
2.6.22 is the first kernel where we removed IPv4 only conntrack.
My guess is that some of the necessary modules aren't loaded,
we were missing a dependency or two in the beginning. Specifically,
IIRC the NAT module didn't pull in nf_conntrack_ipv4, so please
make sure that module is loaded. In case it is, please post
the full list of loaded modules.
As I told in my starting message I suspect the problem if from pppoe, not iptables, but I can't change the assigne for the bug. BTW, here the tcpdump from the gateway (IP have been changed): root@gateway /root >tcpdump -n -i ppp0 icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes 21:57:26.210735 IP 151.71.34.56 > 192.138.243.126: ICMP echo request, id 62492, seq 1, length 64 21:57:27.209276 IP 151.71.34.56 > 192.138.243.126: ICMP echo request, id 62492, seq 2, length 64 21:57:28.209282 IP 151.71.34.56 > 192.138.243.126: ICMP echo request, id 62492, seq 3, length 64 21:57:29.209478 IP 151.71.34.56 > 192.138.243.126: ICMP echo request, id 62492, seq 4, length 64 21:57:30.209050 IP 151.71.34.56 > 192.138.243.126: ICMP echo request, id 62492, seq 5, length 64 21:57:31.209059 IP 151.71.34.56 > 192.138.243.126: ICMP echo request, id 62492, seq 6, length 64 In the same time, this is the tcpdump on the internet machine : root@internetmachine:~# tcpdump -n -i eth0 icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 21:57:26.301804 IP 151.71.34.56 > 192.138.243.126: ICMP echo request, id 62492, seq 1, length 64 21:57:26.301847 IP 192.138.243.126 > 151.71.34.56: ICMP echo reply, id 62492, seq 1, length 64 21:57:27.300051 IP 151.71.34.56 > 192.138.243.126: ICMP echo request, id 62492, seq 2, length 64 21:57:27.300094 IP 192.138.243.126 > 151.71.34.56: ICMP echo reply, id 62492, seq 2, length 64 21:57:28.300018 IP 151.71.34.56 > 192.138.243.126: ICMP echo request, id 62492, seq 3, length 64 21:57:28.300057 IP 192.138.243.126 > 151.71.34.56: ICMP echo reply, id 62492, seq 3, length 64 21:57:29.300209 IP 151.71.34.56 > 192.138.243.126: ICMP echo request, id 62492, seq 4, length 64 21:57:29.300248 IP 192.138.243.126 > 151.71.34.56: ICMP echo reply, id 62492, seq 4, length 64 21:57:30.299660 IP 151.71.34.56 > 192.138.243.126: ICMP echo request, id 62492, seq 5, length 64 21:57:30.299702 IP 192.138.243.126 > 151.71.34.56: ICMP echo reply, id 62492, seq 5, length 64 21:57:31.299785 IP 151.71.34.56 > 192.138.243.126: ICMP echo request, id 62492, seq 6, length 64 21:57:31.299826 IP 192.138.243.126 > 151.71.34.56: ICMP echo reply, id 62492, seq 6, length 64 and the ping from the client root@client /root >ping 192.138.243.126 PING 192.138.243.126 (192.138.243.126) 56(84) bytes of data. ^C --- 192.138.243.126 ping statistics --- 6 packets transmitted, 0 received, 100% packet loss, time 4999ms and the lsmod when not working ( nf_conntrack_ipv4 is loaded ) root@gateway /root >lsmod Module Size Used by lp 10052 0 parport_pc 23492 1 parport 23168 2 lp,parport_pc ipt_owner 1728 4 ipt_MASQUERADE 3168 1 ipt_REJECT 4192 3 iptable_mangle 2560 1 xt_MARK 2016 6 xt_multiport 2848 2 xt_tcpudp 2880 89 xt_state 2208 3 iptable_nat 6948 1 nf_nat 16364 2 ipt_MASQUERADE,iptable_nat nf_conntrack_ipv4 15852 5 iptable_nat nf_conntrack 56120 5 ipt_MASQUERADE,xt_state,iptable_nat,nf_nat,nf_conntrack_ipv4 iptable_filter 2688 1 ip_tables 11176 3 iptable_mangle,iptable_nat,iptable_filter x_tables 13604 9 ipt_owner,ipt_MASQUERADE,ipt_REJECT,xt_MARK,xt_multiport,xt_tcpudp,xt_state,iptable_nat,ip_tables bsd_comp 5248 0 ppp_synctty 8352 0 ppp_async 9920 1 crc_ccitt 1920 1 ppp_async bridge 48504 0 llc 6964 1 bridge tun 10304 1 snd_seq_oss 27936 0 snd_seq_midi_event 6336 1 snd_seq_oss snd_seq 42224 4 snd_seq_oss,snd_seq_midi_event snd_seq_device 7468 2 snd_seq_oss,snd_seq snd_pcm_oss 38304 0 snd_mixer_oss 15104 1 snd_pcm_oss ipv6 221284 26 e100 32332 0 agpgart 30992 0 pcmcia 39288 0 firmware_class 9120 1 pcmcia snd_intel8x0 30940 0 snd_ac97_codec 91008 1 snd_intel8x0 ac97_bus 2016 1 snd_ac97_codec snd_pcm 68584 3 snd_pcm_oss,snd_intel8x0,snd_ac97_codec snd_timer 19428 2 snd_seq,snd_pcm snd 46340 9 snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_intel8x0,snd_ac97_codec,snd_pcm,snd_timer snd_page_alloc 9288 2 snd_intel8x0,snd_pcm 8250_pci 20064 0 serio_raw 6212 0 8250 20884 1 8250_pci eepro100 28176 0 serial_core 18624 1 8250 yenta_socket 24492 2 rsrc_nonstatic 10272 1 yenta_socket pcmcia_core 38452 3 pcmcia,yenta_socket,rsrc_nonstatic as you may see, on the gateway there is not reply received, thus the conntrack cannot do nothing. In the 2.6.21.7 kernel, I can see the reply on the gateway, and the conntrack have some "food" to work with. Cheers Pigi Could you try to set this option (and proc/ according to the config comment)?: # CONFIG_IP_ADVANCED_ROUTER is not set If it doesn't help, please, show tcpdumps from the router (on ppp0) and this internet box while pinging from the client. (It would be nice to try this with more current kernel version.) Thanks, Jarek P. Seems that 2.6.28.2 is working. Probably the problem was my fault on selecting the right kernel configs for the new NF framewark, also if I haven't seen differences in the NF NAT area in the 2.6.26 config and 2.6.28.2 BTW now it's working, so if you agree, can close. |