I'm trying again to bring to your attention what seems to me an alignment
problem/bug when running pppoatm.
The stack on receive path:
atm drivers: alloc_skb and hand-off aligned skb to pppoatm_push()
pppoatm: pppoatm_push strips 4 bytes LLC header (if LLC-ENCAPS mode used)
(no extra header if VC-MUX is used) and
hand-off skb to ppp_input().
ppp_generic: ppp_receive_nonmp_frame():
(no VJ compression used):
skb_pull(skb, 2); /* chop off protocol */
netif_rx(skb);
The end result will be that the kernel gets now a
misaligned skb (we removed a total of 6 bytes).
and under some conditions (easy to replicate) a simple
tcp session will fail (run ttcp -r from this end to any
host and you will get TCP RST caused by the above
misalignment or run a telnet session from a client to this
box over the DSL/ATM interface).
Just to prove myself right on this, I cloned the skb in
ppp_generic:ppp_receive_nomp_frame() and before
skb_pull(skb,2) I allocate a new skb and do
skb_reserve(cloned_skb, 2). WORKS.
This fixes the above problem. but at the expense of a new skb allocation and
copy per packet. NOT quite acceptable.
If you try to do the alignment correction in the driver will fail (see below
why and where).
If we follow the stack:
1)ATM cannot to this correction for alignment because you can run pppoe on top
of it or br2684 and they all have their own headers of different length.
2)PPPoATM cannot to this because the 2 byte protocol ID is part of the packets
with payload but PPP run its won LCP connection establishment session and
packets there are with different headers (don't know all the details of ppp).
3) It is only PPP that can correct the alignment.
Question is: How to do this w/out alloc & copy a new skb ?
This is different from the ethernet driver where we can account for the 16
bytes IP align since we are going to send up on the stack only ethernet
packets, all with same IP offset.
Does anyone out there uses PPPoATM in linux with current patches ?
Have you seen this problem ? I would be interested in how other people solved
this problem.
Just to mention here that, w/out the correction on alignment, I can run w/out
problems IP traffic thru this box (router mode). The problems are when
delivering this up on the local stack (tcp) and packet inspection is more
carefully (in my case I get it to fail in tcp_input.c (2.4.17 kernel)
3412 if (th->syn && !before(TCP_SKB_CB(skb)->seq, tp->rcv_nxt)) {
3413 TCP_INC_STATS_BH(TcpInErrs);
3414 NET_INC_STATS_BH(TCPAbortOnSyn);
3415 tcp_reset(sk);
3416 return 1;
3417 }
But I believe that this is a particular case, e.g. tyr to telnet over the DSL
interface to such a box and will get an RST right away (i didn't trace this
session). So the TCP sessions are going to fail at some point due to several
places where alignment is checked.
Thanks for your input,
Marian Stagarescu
On Thursday 25 July 2002 10:33 pm, marian stagarescu wrote:
> I run into some problems with PPPoATM :
> I have a 2.4.17 kernel patched for pppoatm, pppd 2.4.1 patched for pppoatm,
> linux-atm-2.4.0, built with uclibc on a MIPS-based board.
>
> Running this system into routed mode:
>
>
> ip_forward=1
> +--------------+
> internet--dsl---|pppoatm eth|----LAN
> +--------------+
>
> I can access Internet from LAN and vice versa w/out problems.
>
> Now, if I try to run a simple ftp from this gateway over the PPPoATM/DSL
> side
>
> +--------------+
> internet--dsl---|pppoatm |
> +--------------+
>
> it breaks (FTP/TCP client on this gateway send an RST after few packets).
> Same TCP reset is sent from the box, if I try to telnet to this box from
> outside over DSL. Ping works. I tried both modes (LLC-Encaps and VC-MUX)
> w/out results. Breaks.
>
> All of the above works if I do it over Ethernet side. so the build is ok.
>
>
> In the past I had some similar problems over the ATM driver and Eth driver
> and turned out to be an SKB ALIGNMENT problem on the driver side.
> This time I checked and I have my skb aligned.
>
> I wonder, in case of PPPoATM, I pass an aligned skb->data up to
> pppoatm_push(), which strips (in case of LLC) 4 bytes off (Fe FE 03 CF)
> and passes up to ppp_input(), which strips 2 more bytes (00 21) and passes
> it to netif_rx(). Doesn't this end up misaligned ?
> PPPoATM does strip 4 bytes (for LLC) so passing it on is still aligned.
> what about ppp_generic ?
>
> In case of Eth where we strip 14 bytes typically a driver will
> dev_skb_alloc(pdu_len +2) / skb_reserve(skb,2).
> Where/How we do this alignment for pppoatm/llc-encaps ?
>
> Thanks,
> Marian
>
>
>
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: Jabber - The world's fastest growing
> real-time communications platform! Don't just IM. Build it in!
> http://www.jabber.com/osdn/xim
> _______________________________________________
> Linux-atm-general mailing list
> Linux-atm-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-atm-general
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
