Re: [Linux-ATM-General] br2684 : sent packets truncated in VC routed mode

[Pascal H. <pa...@pl...>]

Hello,

Eric Kinzie (contractor) a écrit :
> 
> Changing the -p option to "1" will put an ethernet header in each pdu.
> See rfc 1483 section 4.1 for a description of the "routed" configuration
> (-p 0).
> 
> # br2684ctl -c 0 -e 0 -p 1 -a 8.36

I don't want to put an ethernet header. The encapsulation on this ADSL
line is RFC1483/2684 VC-MUX routed IP, not bridged ethernet.

Maybe I was not clear enough. Below is more concrete information about
the issue.

Here is my test setup :

# load atmarp kernel module
modprobe atmtcp
# create virtual ATM interface 1 and print PDUs
atmtcp virtual 1 print &

* First test using br2684ctl :

# create a point-to point interface nas0 using VC-MUX routed mode
br2684ctl -c 0 -e 1 -p 0 -a 1.8.35 &
# configure network interface nas0
ifconfig nas0 192.168.9.1 pointopoint 192.168.9.2
# send an IP packet on the PVC
ping -n -c 1 192.168.9.2

Result:
Link 1 (from link 0), VPI 8, VCI 35, 70 bytes:
  09 01 c0 a8 09 02 08 00 68 8d 05 cc 00 01 8b 98
  30 4e de bb 04 00 08 09 0a 0b 0c 0d 0e 0f 10 11
  12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21
  22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31
  32 33 34 35 36 37

* Second test using atmarp :

# create a classical IP over ATM interface atm0
atmarp -c 0
# configure network interface atm0
ifconfig atm0 192.168.9.1 netmask 255.255.255.0 mtu 1500
# create a static ATMARP entry for address 192.168.9.2 with null
(VC-MUX) encapsulation
atmarp -s 192.168.9.2 1.8.35 null
# send an IP packet on the PVC
ping -n -c 1 192.168.9.2

Result:
Link 1 (from link 0), VPI 8, VCI 35, 84 bytes:
  45 00 00 54 00 00 40 00 40 01 a7 55 c0 a8 09 01
  c0 a8 09 02 08 00 a9 96 05 e6 00 01 a0 99 30 4e
  82 97 0a 00 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13
  14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23
  24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33
  34 35 36 37

AFAIK, RFC1483/2684 VC-MUX routed IP encapsulation puts just the bare IP
packet in the PDU payload. This is what the second test result shows.
But the first test result shows that 14 bytes are missing from the
beginning of the IP packet, due to the skb_pull(skb, ETH_HLEN) call in
net/atm/br2684.c. This is not the expected behaviour in the RFC, is it ?

Note that there is no such call for LLC/SNAP routed encapsulation : the
LLC/SNAP header is just inserted before the IP packet.