linux-atm-general — General discussion of ATM networking under linux

[Linux-ATM-General] [RFC][PATCH 0/2] atm: br2682: Improve encapsulation checks and headroom allocation

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

Hello,

Here are two small patches for the br2684 kernel module against the 3.0
source tree. I adapted and tested them briefly on the 2.6.32 kernel I
currently use, using a pair of virtual ATM interfaces created by atmarp.

These are my first kernel patches, so please bear with me.

[PATCH 1/2] atm: br2684: Improve encapsulation checks

 - Check that the LLC header matches the expected payload type.
 - Remove the FCS bytes only if the PID is ethernet with FCS.
 - Check the data length before removing the FCS or padding bytes.

Accepting a PDU with the wrong LLC encapsulation could do nasty things.
I triggered a kernel panic by sending an LLC routed PDU to an LLC
bridged interface on a default 2.6.32 Debian kernel.

Discussion :
Should we check the padding bytes value in received bridged PDUs ?
Or should we follow the saying "be conservative in what you send, and
liberal in what you accept" ?
Currently, it is checked in VC-MUX mode, but not in LLC mode.

[PATCH 2/2] atm: br2684: Do not allocate more headroom than needed

 Routed encapsulation requires less headroom than bridged encapsulation.

[Linux-ATM-General] [PATCH 1/1] atm: br2864: sent packets truncated in VC routed mode

[chas w. - C. <ch...@cm...>]

hopefully this could be included for the next kernel release.

From: chas williams - CONTRACTOR <ch...@cm...>

commit 8b5e1c9db2bcd2d13c2db08e6c6dbe66882fa186
Author: chas williams - CONTRACTOR <ch...@cm...>
Date:   Mon Aug 1 07:55:07 2011 -0400

    atm: br2864: sent packets truncated in VC routed mode
    
    Reported-by: Pascal Hambourg <pa...@pl...>
    Signed-off-by: Chas Williams <ch...@cm...>

diff --git a/net/atm/br2684.c b/net/atm/br2684.c
index 2252c20..52cfd0c 100644
--- a/net/atm/br2684.c
+++ b/net/atm/br2684.c
@@ -242,8 +242,6 @@ static int br2684_xmit_vcc(struct sk_buff *skb, struct net_device *dev,
 		if (brdev->payload == p_bridged) {
 			skb_push(skb, 2);
 			memset(skb->data, 0, 2);
-		} else { /* p_routed */
-			skb_pull(skb, ETH_HLEN);
 		}
 	}
 	skb_debug(skb);

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

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

chas williams - CONTRACTOR wrote :
> On Thu, 28 Jul 2011 21:10:38 +0200
> Francois Romieu <ro...@fr...> wrote:
> 
>> A short explanation of the skb_pull(skb, ETH_HLEN) for e_vc/p_routed in
>> br2684_xmit_vcc would be welcome.
>>
>> I do not see how there can be ETH_HLEN excess bytes in this direction.
> 
> yeah, i think this skb_pull() is wrong.  when a routed interface is
> setup, it shouldnt be prepending ethernet headers on the outgoing
> packets so there shouldnt be any need to remove an ethernet header.
> 
> anyone willing/capable of testing a patch?

A test with an ADSL line using VC-MUX routed encapsulation for internet
access through a Sagem Fast 800 USB modem (ueagle-atm) was successful.
The internet connection worked fine.

Command line : br2684ctl -c 0 -e 1 -p 0 -a 8.36

Below is a (trivial) patch against kernel 3.0 adapted from the one I
applied to my kernel 2.6.32.

diff -ur a/net/atm/br2684.c b/net/atm/br2684.c
--- a/net/atm/br2684.c	2011-07-30 19:13:26.000000000 +0200
+++ b/net/atm/br2684.c	2011-07-30 19:26:28.000000000 +0200
@@ -242,8 +242,6 @@
 		if (brdev->payload == p_bridged) {
 			skb_push(skb, 2);
 			memset(skb->data, 0, 2);
-		} else { /* p_routed */
-			skb_pull(skb, ETH_HLEN);
 		}
 	}
 	skb_debug(skb);

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

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

Karl Hiramoto a écrit :
> On 7/29/2011 12:30 PM, chas williams - CONTRACTOR wrote:
>> On Thu, 28 Jul 2011 21:10:38 +0200
>> Francois Romieu<ro...@fr...>  wrote:
>>
>>> A short explanation of the skb_pull(skb, ETH_HLEN) for e_vc/p_routed in
>>> br2684_xmit_vcc would be welcome.
>>>
>>> I do not see how there can be ETH_HLEN excess bytes in this direction.
>>>
>> yeah, i think this skb_pull() is wrong.  when a routed interface is
>> setup, it shouldnt be prepending ethernet headers on the outgoing
>> packets so there shouldnt be any need to remove an ethernet header.
>>
>> anyone willing/capable of testing a patch?
> 
> FWIW   I tested  br2684 with a ADSL DSLAM I have access to, in routed 
> mode about a year ago with 2.6.32 and all worked fine.

Was the encapsulation method LLC or VC-MUX ?

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

[Karl H. <ka...@hi...>]

On 7/29/2011 12:30 PM, chas williams - CONTRACTOR wrote:
> On Thu, 28 Jul 2011 21:10:38 +0200
> Francois Romieu<ro...@fr...>  wrote:
>
>> Eric Kinzie (contractor)<ek...@cm...>  :
>> [...]
>>> 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).
>> A short explanation of the skb_pull(skb, ETH_HLEN) for e_vc/p_routed in
>> br2684_xmit_vcc would be welcome.
>>
>> I do not see how there can be ETH_HLEN excess bytes in this direction.
>>
> yeah, i think this skb_pull() is wrong.  when a routed interface is
> setup, it shouldnt be prepending ethernet headers on the outgoing
> packets so there shouldnt be any need to remove an ethernet header.
>
> anyone willing/capable of testing a patch?
>

FWIW   I tested  br6684 with a ADSL DSLAM I have access to, in routed 
mode about a year ago with 2.6.32 and all worked fine.   Since then I 
haven't tested routed RFC2684 in some time.


--
Karl

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

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

chas williams - CONTRACTOR wrote :
> Francois Romieu <ro...@fr...> wrote:
> 
>> A short explanation of the skb_pull(skb, ETH_HLEN) for e_vc/p_routed in
>> br2684_xmit_vcc would be welcome.
>>
>> I do not see how there can be ETH_HLEN excess bytes in this direction.
> 
> yeah, i think this skb_pull() is wrong.  when a routed interface is
> setup, it shouldnt be prepending ethernet headers on the outgoing
> packets so there shouldnt be any need to remove an ethernet header.

Besides, there is no such operation in the code for LLC routed encapsulation.

> anyone willing/capable of testing a patch?

As I wrote in my initial message, I commented out skb_pull(skb, ETH_HLEN)
and now PDUs transmitted on a virtual interface look correct when printed
by atmtcp. I am planning to do a real test on an ADSL line with VC-MUX
routed encapsulation tomorrow.

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

[chas w. - C. <ch...@cm...>]

On Thu, 28 Jul 2011 21:10:38 +0200
Francois Romieu <ro...@fr...> wrote:

> Eric Kinzie (contractor) <ek...@cm...> :
> [...]
> > 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).
> 
> A short explanation of the skb_pull(skb, ETH_HLEN) for e_vc/p_routed in
> br2684_xmit_vcc would be welcome.
> 
> I do not see how there can be ETH_HLEN excess bytes in this direction.
> 

yeah, i think this skb_pull() is wrong.  when a routed interface is
setup, it shouldnt be prepending ethernet headers on the outgoing
packets so there shouldnt be any need to remove an ethernet header.

anyone willing/capable of testing a patch?

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

[Francois R. <ro...@fr...>]

Eric Kinzie (contractor) <ek...@cm...> :
[...]
> 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).

A short explanation of the skb_pull(skb, ETH_HLEN) for e_vc/p_routed in
br2684_xmit_vcc would be welcome.

I do not see how there can be ETH_HLEN excess bytes in this direction.

-- 
Ueimor

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.

Re: [Linux-ATM-General] protocol confusion.

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

Hello,

Karl Hiramoto a écrit :
> On 07/27/11 16:19, Pascal Hambourg wrote:
>>
>> I tried to setup an IPoA over ADSL connection in VC routed mode with
>> br2684ctl at a friend's house :
>>
>> # br2684ctl -c 0 -e 1 -p 0 -a 8.36
> IPoA/CLIP (RFC1577) is NOT the same as RFC2864 so your using the wrong
> protocol, which explains  your encapsulation/framing problems.
> 
> You should  use atmarpd instead.

I don't think so. The encapsulation on this ADSL line is RFC1483/2684
VC-MUX routed IP. There is no ATMARP. I just used atmarp with a static
entry as a hack to specify the PVC because Classical IP uses the routed
encapsulation defined in RFC1483/2684.

Re: [Linux-ATM-General] protocol confusion.

[Karl H. <ka...@hi...>]

On 07/27/11 16:19, Pascal Hambourg wrote:
> Hello,
>
> I tried to setup an IPoA over ADSL connection in VC routed mode with
> br2684ctl at a friend's house :
>
> # br2684ctl -c 0 -e 1 -p 0 -a 8.36
IPoA/CLIP (RFC1577) is NOT the same as RFC2864 so your using the wrong
protocol, which explains  your encapsulation/framing problems.

You should  use atmarpd instead.


> and configured the nas0 interface with ifconfig. No error message, but no
> replies to sent packets were received. Then I setup a CLIP interface with
> atmarp in VC mode instead :
>
> # atmarp -c 0
> # ifconfig atm0 <address> netmask <netmask> up mtu 1500
> # atmarp -s <gateway> 8.36 null
>
> and the connection worked well.
>
> Back home, I investigated using atmtcp to print sent PDUs, and found out
> that in PDUs generated by br2684 the 14 first bytes were missing, while
> they were present when generated by atmarp.
>
> Looking at net/atm/br2684.c in the kernel source, in function
> br2684_xmit_vcc() I found :
>
> 	} else { /* e_vc */
> 		if (brdev->payload == p_bridged) {
> 			skb_push(skb, 2);
> 			memset(skb->data, 0, 2);
> 		} else { /* p_routed */
> 			skb_pull(skb, ETH_HLEN);
>
> Hmm, indeed 14 bytes is just the size of an ethernet header, but it makes
> no sense on a point-to-point interface. I commented out the last line and
> rebuilt the br2684 module, and now sent PDUs look complete. However I have
> not been able to test for real yet as I don't have an IPoA connection.
>
> The line was added by commit 7e903c2ae36efb526eacab3b25d00e90424bd8a8
> atm: [br2864] fix routed vcmux support
>
> Any comments ? Maybe I missed something, I can hardly believe
> such an issue could have remained unnoticed for such a long time.
>
> Thanks.
>
>
> ------------------------------------------------------------------------------
> Got Input?   Slashdot Needs You.
> Take our quick survey online.  Come on, we don't ask for help often.
> Plus, you'll get a chance to win $100 to spend on ThinkGeek.
> http://p.sf.net/sfu/slashdot-survey
> _______________________________________________
> Linux-atm-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-atm-general

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

[Eric K. (contractor) <ek...@cm...>]

On Wed Jul 27 16:43:33 +0200 2011, Pascal Hambourg wrote:
> [Sorry for the previous message with an empty subject]
> 
> Hello,
> 
> I tried to setup an IPoA over ADSL connection in VC routed mode with
> br2684ctl at a friend's house :
> 
> # br2684ctl -c 0 -e 1 -p 0 -a 8.36
> 
> and configured the nas0 interface with ifconfig. No error message, but no
> replies to sent packets were received. Then I setup a CLIP interface with
> atmarp in VC mode instead :
> 
> # atmarp -c 0
> # ifconfig atm0 <address> netmask <netmask> up mtu 1500
> # atmarp -s <gateway> 8.36 null
> 
> and the connection worked well.
> 
> Back home, I investigated using atmtcp to print sent PDUs, and found out
> that in PDUs generated by br2684 the 14 first bytes were missing, while
> they were present when generated by atmarp.
> 
> Looking at net/atm/br2684.c in the kernel source, in function
> br2684_xmit_vcc() I found :
> 
> 	} else { /* e_vc */
> 		if (brdev->payload == p_bridged) {
> 			skb_push(skb, 2);
> 			memset(skb->data, 0, 2);
> 		} else { /* p_routed */
> 			skb_pull(skb, ETH_HLEN);
> 
> Hmm, indeed 14 bytes is just the size of an ethernet header, but it makes
> no sense on a point-to-point interface. I commented out the last line and
> rebuilt the br2684 module, and now sent PDUs look complete. However I have
> not been able to test for real yet as I don't have an IPoA connection.
> 
> My kernel version is 2.6.32.x but this part has not changed in newer
> versions.
> 
> The line was added by commit 7e903c2ae36efb526eacab3b25d00e90424bd8a8 atm:
> [br2864] fix routed vcmux support
> 
> Any comments ? Maybe I missed something, I can hardly believe
> such an issue could have remained unnoticed for such a long time.

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

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

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

[Sorry for the previous message with an empty subject]

Hello,

I tried to setup an IPoA over ADSL connection in VC routed mode with
br2684ctl at a friend's house :

# br2684ctl -c 0 -e 1 -p 0 -a 8.36

and configured the nas0 interface with ifconfig. No error message, but no
replies to sent packets were received. Then I setup a CLIP interface with
atmarp in VC mode instead :

# atmarp -c 0
# ifconfig atm0 <address> netmask <netmask> up mtu 1500
# atmarp -s <gateway> 8.36 null

and the connection worked well.

Back home, I investigated using atmtcp to print sent PDUs, and found out
that in PDUs generated by br2684 the 14 first bytes were missing, while
they were present when generated by atmarp.

Looking at net/atm/br2684.c in the kernel source, in function
br2684_xmit_vcc() I found :

	} else { /* e_vc */
		if (brdev->payload == p_bridged) {
			skb_push(skb, 2);
			memset(skb->data, 0, 2);
		} else { /* p_routed */
			skb_pull(skb, ETH_HLEN);

Hmm, indeed 14 bytes is just the size of an ethernet header, but it makes
no sense on a point-to-point interface. I commented out the last line and
rebuilt the br2684 module, and now sent PDUs look complete. However I have
not been able to test for real yet as I don't have an IPoA connection.

My kernel version is 2.6.32.x but this part has not changed in newer
versions.

The line was added by commit 7e903c2ae36efb526eacab3b25d00e90424bd8a8 atm:
[br2864] fix routed vcmux support

Any comments ? Maybe I missed something, I can hardly believe
such an issue could have remained unnoticed for such a long time.

Thanks.

[Linux-ATM-General] (no subject)

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

Hello,

I tried to setup an IPoA over ADSL connection in VC routed mode with
br2684ctl at a friend's house :

# br2684ctl -c 0 -e 1 -p 0 -a 8.36

and configured the nas0 interface with ifconfig. No error message, but no
replies to sent packets were received. Then I setup a CLIP interface with
atmarp in VC mode instead :

# atmarp -c 0
# ifconfig atm0 <address> netmask <netmask> up mtu 1500
# atmarp -s <gateway> 8.36 null

and the connection worked well.

Back home, I investigated using atmtcp to print sent PDUs, and found out
that in PDUs generated by br2684 the 14 first bytes were missing, while
they were present when generated by atmarp.

Looking at net/atm/br2684.c in the kernel source, in function
br2684_xmit_vcc() I found :

	} else { /* e_vc */
		if (brdev->payload == p_bridged) {
			skb_push(skb, 2);
			memset(skb->data, 0, 2);
		} else { /* p_routed */
			skb_pull(skb, ETH_HLEN);

Hmm, indeed 14 bytes is just the size of an ethernet header, but it makes
no sense on a point-to-point interface. I commented out the last line and
rebuilt the br2684 module, and now sent PDUs look complete. However I have
not been able to test for real yet as I don't have an IPoA connection.

The line was added by commit 7e903c2ae36efb526eacab3b25d00e90424bd8a8
atm: [br2864] fix routed vcmux support

Any comments ? Maybe I missed something, I can hardly believe
such an issue could have remained unnoticed for such a long time.

Thanks.

Re: [Linux-ATM-General] Multiple IP addresses on an ATM interface

[chas w. - C. <ch...@cm...>]

On Fri, 15 Jul 2011 08:33:15 -0700
"Sjoberg, Jon" <Jon...@go...> wrote:

> I'm trying to configure multiple IP addresses on the same physical ATM
> interface and VP.  In the system I have I need to be able to configure
> PVCs for all of the following on the same physical ATM interface:
> - Have two IP addresses in the same subnet but different PVC's
> - Have one IP address on a different subnet then the two above, also
> with its own PVC
> - Have multiple PVC's per IP address, each PVC to a different IP address
> - Have multiple AAL5 PVC's on the interface
>  
> For example I have the following PVCs, on one physical ATM interface:
> ENCODING    IP           VCI
> IPOA       10.20.30.1    100
> IPOA       10.20.30.2    101
> IPOA       192.168.20.1  103
> AAL5        -----        104
>  
> What commands would I need to get this through ATMAPR/ifconfig/etc.?  
>  
> I have tried using virtual interfaces (e.g. "atm0:0"), but the atmarp
> program does not seem ready for that so I suspect that was not the right
> way to go.

you probably want to use br2684ctl instead of atmarp.

first/second case you will likely need use routed mode on br2684ctl so
you can create a pointopoint ip interface and then use ifconfig to
setup the endpoints on each ip interface.  something like:

	br2684ctl -c 1 -p 0 -a 0.0.100 &
	br2684ctl -c 2 -p 0 -a 0.0.101 &
	ifconfig nas1 10.20.30.99 pointopoint 10.20.30.1
	ifconfig nas2 10.20.30.99 pointopoint 10.20.30.2

the third case:

	br2684ctl -c 3 -p 0 -a 0.0.103 &
	ifconfig nas3 192.168.20.2 pointopoint 192.168.20.1

the last case should be explain simply enough by the man page.
however, it is bridge mode not routed (-p 1).

you can still do this with atmarp and a clip interface however you dont
need to worry about atm0:0.  you can assign multiple ip address to the
same ip interface using the 'ip' command.

[Linux-ATM-General] Multiple IP addresses on an ATM interface

[Sjoberg, J. <Jon...@go...>]

I'm trying to configure multiple IP addresses on the same physical ATM
interface and VP.  In the system I have I need to be able to configure
PVCs for all of the following on the same physical ATM interface:
- Have two IP addresses in the same subnet but different PVC's
- Have one IP address on a different subnet then the two above, also
with its own PVC
- Have multiple PVC's per IP address, each PVC to a different IP address
- Have multiple AAL5 PVC's on the interface
 
For example I have the following PVCs, on one physical ATM interface:
ENCODING    IP           VCI
IPOA       10.20.30.1    100
IPOA       10.20.30.2    101
IPOA       192.168.20.1  103
AAL5        -----        104
 
What commands would I need to get this through ATMAPR/ifconfig/etc.?  
 
I have tried using virtual interfaces (e.g. "atm0:0"), but the atmarp
program does not seem ready for that so I suspect that was not the right
way to go.
 
Thanks for any help,
Jon

Re: [Linux-ATM-General] [PATCH] ATM: Fix wrong usage of INIT_WORK

[chas w. - C. <ch...@cm...>]

On Thu, 7 Jul 2011 20:04:25 +0800
Wang Shaoyan <stu...@gm...> wrote:

> I just don't know whether the marco FILL_RX_POOLS_IN_BH is useful?

the macro doesnt seem to be useful in anyway.  it can simply be
eliminated.

Re: [Linux-ATM-General] [PATCH 2/3] ADSL: Carrier Handling and PPP support

[chas w. - C. <ch...@cm...>]

On Sat, 28 May 2011 12:55:25 +0100
David Woodhouse <dw...@in...> wrote:

> However, it's not clear how we're then supposed to work out what name it
> created for us. Perhaps we need something like...

this would be the best choice IMO.  just choose the name you want to
create.  if it fails, you will need to pick another like 'nas1'.  you
can always not use the nas prefix to prevent collision with other
br2684 users who are likely relying on the default interface names.

> Strictly speaking, that's an ABI change for an existing ioctl, and thus
> quite naughty. But since I don't think there *are* currently any users
> of that ioctl outside br2684ctl, I suspect we'd get away with it...

i think you might need to change the ioctl from _IOW() to _IOWR() as
well.  this would change the ioctl number i think and create more
trouble than you would like.

Re: [Linux-ATM-General] [PATCH 2/3] ADSL: Carrier Handling and PPP support

[David W. <dw...@in...>]

On Tue, 2011-05-31 at 07:55 -0400, chas williams - CONTRACTOR wrote:
> 
> this would be the best choice IMO.  just choose the name you want to
> create.  if it fails, you will need to pick another like 'nas1'.  

Ok. We already have similar code for 'vpn%d' anyway, for creating tun
devices 'in advance' so that they can then be used by a VPN dæmon
running as a non-root user:

        for (i = 0; i < 256; i++) {
                if (tun_name)
                        g_free(tun_name);

                sprintf(ifr.ifr_name, "vpn%d", i);
                
                if (!ioctl(fd, TUNSETIFF, (void *)&ifr))
                        break;
        }

-- 
dwmw2

Re: [Linux-ATM-General] [PATCH 2/3] ADSL: Carrier Handling and PPP support

[David W. <dw...@in...>]

On Thu, 2011-05-26 at 12:58 -0500, Dan Williams wrote:
> On Sun, 2011-05-22 at 22:12 +0100, David Woodhouse wrote:
> > You are hard-coding the name 'nas0' for the virtual Ethernet interface,
> > which you shouldn't. And I think I'd be tempted not to use the separate
> > br2684ctl program; the amount of code you have to 'manage' the external
> > tool *far* exceeds the amount of relevant code in br2684ctl.c itself :)
> 
> If that's the case maybe we should just do it all internally to NM and
> then not have to depend on br2684ctl; though I haven't looked at the
> amount of code in there to figure out what's going on.
> 
> But yeah, we can't hardcode nas0 in the long run, but how do we get the
> kernel to dynamically assign us a device name?  Or do we have to manage
> that crap ourselves?

As long as we're not using br2684ctl, we can just pass an empty name in
the ATM_NEWBACKENDIF ioctl and the kernel will create a 'nas%d' name for
us automatically.

However, it's not clear how we're then supposed to work out what name it
created for us. Perhaps we need something like...

diff --git a/net/atm/br2684.c b/net/atm/br2684.c
index 2252c20..fd45786 100644
--- a/net/atm/br2684.c
+++ b/net/atm/br2684.c
@@ -652,6 +652,14 @@ static int br2684_create(void __user *arg)
 	if (!netdev)
 		return -ENOMEM;
 
+	if (!ni.ifname[0] &&
+	    copy_to_user (&netdev->name,
+			  arg + offsetof (struct atm_newif_br2684, ifname),
+			  strlen(netdev->name) + 1)) {
+		free_netdev(netdev);
+		return -EFAULT;
+	}
+
 	brdev = BRPRIV(netdev);
 
 	pr_debug("registered netdev %s\n", netdev->name);

Strictly speaking, that's an ABI change for an existing ioctl, and thus
quite naughty. But since I don't think there *are* currently any users
of that ioctl outside br2684ctl, I suspect we'd get away with it...

-- 
David Woodhouse                            Open Source Technology Centre
Dav...@in...                              Intel Corporation

Re: [Linux-ATM-General] Fwd: [PATCH 1/1] solos-pci: Don't clear open VCs when we detect carrier state (or state changes)

[David W. <dw...@in...>]

On Fri, 2011-04-29 at 17:26 -0700, Philip Prindeville wrote:
> 
> Well, I thought between netdev and linux-atm that all of the
> interested parties would be covered. 

FSVO 'covered'. I'll have received *both* of those, but won't have
actually *seen* them. I don't actually check *either* of those folders
very often.

A direct Cc on solos-pci stuff would be much appreciated; thanks.

-- 
dwmw2

Re: [Linux-ATM-General] Fwd: [PATCH 1/1] solos-pci: Don't clear open VCs when we detect carrier state (or state changes)

[Philip P. <phi...@re...>]

On 4/29/11 4:05 PM, David Woodhouse wrote:
> On Sun, 2011-03-27 at 12:36 -0700, Philip Prindeville wrote:
>> By the way, I need someone to add "Signed-off-by:" to the following
>> patches to speed them along...
>>
>> http://patchwork.ozlabs.org/patch/87650/
>> http://patchwork.ozlabs.org/patch/87676/
>> http://patchwork.ozlabs.org/patch/87965/
>> http://patchwork.ozlabs.org/patch/88026/
>>
>> if anyone is interested in doing so...
> I'd have been interested, but you didn't bother to Cc me...
>

Well, I thought between netdev and linux-atm that all of the interested parties would be covered.

-Philip

Re: [Linux-ATM-General] [PATCH v2 1/1] solos-pci: Fix regression introduced by newest firmware

[David W. <dw...@in...>]

On Mon, 2011-03-21 at 00:25 -0700, Philip Prindeville wrote:
> On 3/20/11 11:04 PM, David Miller wrote:
> > From: Philip Prindeville<phi...@re...>
> > Date: Sun, 20 Mar 2011 22:56:43 -0700
> >
> >> It's not clear that dropping all VCs abruptly when carrier flapped was
> >> ever the right thing to do.
> > So you've tested your change with the older firmware present?
> 
> I haven't, no: back-revving firmware has been known to brick cards.
> 
> I'm waiting to hear back from Guy and Nathan, they have old cards on hand that they can test.

I have JTAG on one of mine and can test, but there's no real need in
this case. If you want to simulate the absence of the 'state changed'
notification, just *ignore* it when it does arrive.

-- 
David Woodhouse                            Open Source Technology Centre
Dav...@in...                              Intel Corporation

Re: [Linux-ATM-General] [PATCH v2 1/1] solos-pci: Fix regression introduced by newest firmware

[David W. <dw...@in...>]

On Sun, 2011-03-20 at 22:11 -0400, MIke Westall wrote:
> I'll be the first to admit that (1) I'm a grouchy old guy who (2) first 
> programmed on an IBM 1620 and then on a 360  Model 30 with 32K ram.  But 
> why oh why do we need to use 9 byte string constants with per character 
> compare to decide if the device is up or not :-(

Because that's the interface that we get from the ADSL RTOS on the
device itself. It returns its status as a string.

Besides, it shouldn't be a per-character compare. I'd hope that on a
64-bit box it ends up being a 64-bit compare, followed perhaps by a
single byte compare.

-- 
dwmw2

Re: [Linux-ATM-General] Fwd: [PATCH 1/1] solos-pci: Don't clear open VCs when we detect carrier state (or state changes)

[David W. <dw...@in...>]

On Sun, 2011-03-27 at 12:36 -0700, Philip Prindeville wrote:
> By the way, I need someone to add "Signed-off-by:" to the following
> patches to speed them along...
> 
> http://patchwork.ozlabs.org/patch/87650/
> http://patchwork.ozlabs.org/patch/87676/
> http://patchwork.ozlabs.org/patch/87965/
> http://patchwork.ozlabs.org/patch/88026/
> 
> if anyone is interested in doing so...

I'd have been interested, but you didn't bother to Cc me...

-- 
David Woodhouse                            Open Source Technology Centre
Dav...@in...                              Intel Corporation