mpls-linux-devel Mailing List for MPLS for Linux (Page 6)
Status: Beta
Brought to you by:
jleu
Menu
▾
▴
mpls-linux-devel — Mailig list for discussing the development of MPLS on Linux
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(7) |
Dec
(8) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(5) |
Feb
(73) |
Mar
(22) |
Apr
(21) |
May
|
Jun
|
Jul
(3) |
Aug
(5) |
Sep
(4) |
Oct
(4) |
Nov
(2) |
Dec
(6) |
| 2005 |
Jan
(5) |
Feb
|
Mar
(6) |
Apr
(11) |
May
(6) |
Jun
(5) |
Jul
(4) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
(9) |
Dec
(15) |
| 2006 |
Jan
(11) |
Feb
(7) |
Mar
(4) |
Apr
(1) |
May
(2) |
Jun
(2) |
Jul
(7) |
Aug
|
Sep
(8) |
Oct
(9) |
Nov
(10) |
Dec
(14) |
| 2007 |
Jan
(11) |
Feb
(9) |
Mar
(39) |
Apr
(7) |
May
(4) |
Jun
(2) |
Jul
(5) |
Aug
(6) |
Sep
(6) |
Oct
(1) |
Nov
(1) |
Dec
(8) |
| 2008 |
Jan
|
Feb
(13) |
Mar
(19) |
Apr
(11) |
May
(16) |
Jun
(6) |
Jul
(2) |
Aug
(4) |
Sep
|
Oct
(5) |
Nov
|
Dec
(16) |
| 2009 |
Jan
(13) |
Feb
(5) |
Mar
|
Apr
|
May
(11) |
Jun
(7) |
Jul
(3) |
Aug
|
Sep
(2) |
Oct
(8) |
Nov
(16) |
Dec
(15) |
| 2010 |
Jan
(6) |
Feb
(5) |
Mar
(1) |
Apr
(14) |
May
(42) |
Jun
(4) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
(4) |
Dec
(1) |
| 2011 |
Jan
(3) |
Feb
|
Mar
|
Apr
(7) |
May
(1) |
Jun
(2) |
Jul
(4) |
Aug
(19) |
Sep
(9) |
Oct
(13) |
Nov
(4) |
Dec
(3) |
| 2012 |
Jan
(2) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
(11) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
(3) |
Dec
(2) |
| 2013 |
Jan
(4) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(7) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
(1) |
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
(2) |
Jul
(2) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(2) |
| 2016 |
Jan
(6) |
Feb
(2) |
Mar
(1) |
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(4) |
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Renato W. <ren...@gm...> - 2010-11-18 20:04:27
|
The code is still available on repo.or.cz*, however we are migrating our git trees to sourceforge. There were only small changes on the MPLS kernel code and related tools, but a lot of improvements on LDP, which is working on determined conditions. I will push all the MPLS related code to sourceforge this weekend. Regards, Renato. * http://repo.or.cz/?a=project_list&s=mpls|jleu 2010/11/17 Jean-Francois Dive <jf...@gm...> > Hello folks, > > I am looking into this project and see that, as reported earlier on the > mailing list, it seems the source of kernel + patch is gone.. exploring the > git tree on sourceforge, but .. > > git clone -b master-mpls git:// > mpls-linux.git.sourceforge.net/gitroot/mpls-linux/linux-kernel > > still leads me to kernel tree without mpls support, same for master. I > guess the intend was to keep a branch and merging to new kernel releases > which is all cool and the way to go, but i guess i am missing something. > > Hence, where is the code ?? :) > > cheers > > J. -- Renato Westphal |
|
From: Jean-Francois D. <jf...@gm...> - 2010-11-17 14:57:15
|
Hello folks, I am looking into this project and see that, as reported earlier on the mailing list, it seems the source of kernel + patch is gone.. exploring the git tree on sourceforge, but .. git clone -b master-mpls git://mpls-linux.git.sourceforge.net/gitroot/mpls-linux/linux-kernel still leads me to kernel tree without mpls support, same for master. I guess the intend was to keep a branch and merging to new kernel releases which is all cool and the way to go, but i guess i am missing something. Hence, where is the code ?? :) cheers J. |
|
From: Scott W. <sw...@go...> - 2010-11-02 21:22:20
|
http://mpls-linux.git.sourceforge.net/git/gitweb.cgi?p=mpls-linux/mpls-linux;a=tree doesn't seem to be working. Anyone have the current trees checked out/compiling? Thanks, Scott -- panem et circenses - a winning strategy for over 2000 years! |
|
From: Антон Д. <lit...@gm...> - 2010-08-06 10:49:43
|
Hello. I had ported mpls patch for 2.6.35-rc2 kernel. -- Anton 'evil-man' Danilov. |
|
From: <jl...@mi...> - 2010-07-10 04:50:14
|
Hello all, I know it has been way too long since I've posted to these lists which is one of the reasons why I am posting tonight. Since the birth of my first daughter in 2005, I have not been able to devote any time to maintaining mpls-linux and as a result much of mpls-linux has fell into disrepair. Recently there has been a flurry of mpls-linux activity, so I know there are people out there using/developing mpls-linux. I'd like to find one or two volunteers who will be willing take an active role in maintaining mpls-linux. To me this means: - track changes to mainline kernel and quagga to keep mpls-linux up to date - build releases in timely manor - co-ordinate development efforts on the lists - gather and integrate patches - re-engage with mainline kernel and quagga developers to discuss possible integration of mpls-linux All interested parties should send me a private email. I will wait until July 16th to make any decisions. At that time I hope to send a joint email with the new maintainer(s) providing the details of how mpls-linux will be maintained going forward. -- James R. Leu jl...@mi... |
|
From: Pali <pal...@gm...> - 2010-06-12 08:39:46
|
Hi Johm, repository was renamed: http://repo.or.cz/w/jleu-ebtables.git http://repo.or.cz/w/jleu-iproute2.git http://repo.or.cz/w/jleu-iptables.git http://repo.or.cz/w/jleu-quagga.git http://repo.or.cz/w/mpls-ldp-portable.git http://repo.or.cz/w/mpls-linux.git http://repo.or.cz/w/mpls-ppp.git and try this: short log: http://repo.or.cz/w/mpls-linux.git/shortlog full log: http://repo.or.cz/w/mpls-linux.git/log 2010/6/11 John Gamboa <vau...@gm...> > Hi... > > On this link > > > http://sourceforge.net/mailarchive/forum.php?thread_name=1266576232.3581.9.camel%40arnaud-laptop&forum_name=mpls-linux-general > > , James Leu said he posted a link for the MPLS patch to the 2.6.31 linux > kernel on the devel mail list some time ago. I tried searching this link, > but I simply can't find. Actually, I am trying to find out if someone has a > patch to the 2.6.30 linux kernel, which is the one I'd like to compile. > > I have the patch to the 2.6.25 linux kernel, which is the patch you get > when you "git clone git://repo.or.cz/mpls-kernel.git". Since I'm n00b on > using git, I don't know if there is any tool I can use to search on the > repository and verify if the patch is there or not. > > Thanks for your help. > > -- > John Gamboa > > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > mpls-linux-devel mailing list > mpl...@li... > https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel > > -- Ak si prajes aby som cital tvoj mail do 5 min, tak napis do predmetu X5. Na skype som dostupny stale, len mi daj vediet aby som sa prihlasil. << 0903 48 47 40 >> mobil << 309458351 >> icq << ortseamo >> skype |
|
From: John G. <vau...@gm...> - 2010-06-11 19:29:52
|
Hi... On this link http://sourceforge.net/mailarchive/forum.php?thread_name=1266576232.3581.9.camel%40arnaud-laptop&forum_name=mpls-linux-general , James Leu said he posted a link for the MPLS patch to the 2.6.31 linux kernel on the devel mail list some time ago. I tried searching this link, but I simply can't find. Actually, I am trying to find out if someone has a patch to the 2.6.30 linux kernel, which is the one I'd like to compile. I have the patch to the 2.6.25 linux kernel, which is the patch you get when you "git clone git://repo.or.cz/mpls-kernel.git". Since I'm n00b on using git, I don't know if there is any tool I can use to search on the repository and verify if the patch is there or not. Thanks for your help. -- John Gamboa |
|
From: <jl...@mi...> - 2010-06-01 13:56:30
|
the git repos have changed names. search for 'mpls|jleu' on the repo.or.cz web interface and you will see the new new repo names. On Tue, Jun 01, 2010 at 10:17:48AM +0200, Pali wrote: > Hi all, > what is the reason that git repositories are closed? Maintenance? > > git clone git://repo.or.cz/mpls-ebtables.git > git clone git://repo.or.cz/mpls-iptables.git > git clone git://repo.or.cz/mpls-iproute2.git > git clone git://repo.or.cz/mpls-kernel.git > > Thank You > ------------------------------------------------------------------------------ > > _______________________________________________ > mpls-linux-devel mailing list > mpl...@li... > https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel -- James R. Leu jl...@mi... |
|
From: Pali <pal...@gm...> - 2010-06-01 08:17:57
|
Hi all, what is the reason that git repositories are closed? Maintenance? git clone git://repo.or.cz/mpls-ebtables.git git clone git://repo.or.cz/mpls-iptables.git git clone git://repo.or.cz/mpls-iproute2.git git clone git://repo.or.cz/mpls-kernel.git Thank You |
|
From: Chris R. <Chr...@nr...> - 2010-05-23 09:43:21
|
James, Jorge Hold the fire hoses. I thought someone had stated mpls-linux had roots in VLAN code so I tested netperf using VLAN tags. It turns out netperf has issues with VLAN tagged packets as well. aka the source system terminates the send with the same "Interrupted system call" error message when sending vlan tagged packets to a target. This is very disappointing, as netperf has been a valuable perf tool. I guess exploration into netperf more is warranted. ....Chris On 05/22/2010 07:01 AM, Chris Robson wrote: > James, Jorge > > Finally have a good (I think) Fedora 12 rpmbuild kernel as pings thru a > LSP between LERs works. However, netperf is failing with "Interrupted > system call" on the netperf side (aka netperf --> netserver). Below is > the mpls debug ping and netperf output as seen from the netserver side). > I need to test using a file seed possible all the zeros is causing mpls > some heart burn, I did test doing using FTP which of course ended up > only using one LSP but it still worked. I will do that later today > using netperf seeded with a file. Is there anything here you observe as > strange? > > > > |
|
From: Chris R. <Chr...@nr...> - 2010-05-22 11:01:53
|
James, Jorge
Finally have a good (I think) Fedora 12 rpmbuild kernel as pings thru a
LSP between LERs works. However, netperf is failing with "Interrupted
system call" on the netperf side (aka netperf --> netserver). Below is
the mpls debug ping and netperf output as seen from the netserver side).
I need to test using a file seed possible all the zeros is causing mpls
some heart burn, I did test doing using FTP which of course ended up
only using one LSP but it still worked. I will do that later today
using netperf seeded with a file. Is there anything here you observe as
strange?
One thing that does bother me is some debug output is missing, even with
"echo "1" > /proc/sys/net/mpls/debug". Possibly I'm missing something
from "sysctl.log" settings?
Also, James, many moons ago I reported issues with 10GE running horribly
slow. At the time it was assumed when building MPLS-Linux, debug was
turned off by default. Ashan's discover suggested another look at the
build files when of course I discovered its on by default. So I will
retest 10GE LSPs next week. But might I suggest that debug be turned
off by default?
...Chris
PING
TESTS--------------------------------------------------------------------------------------
PING
TESTS--------------------------------------------------------------------------------------
PING
TESTS--------------------------------------------------------------------------------------
PING
TESTS--------------------------------------------------------------------------------------
May 22 06:25:05 FEON kernel: MPLS mpls_skb_dump: from eth1 with len 88
(1832)headroom=48 tailroom=1464
May 22 06:25:05 FEON kernel:
0000000000000000505ca30000000005ffff1f00000100000e00ffff010700002020*00051b70e93700051b00475e8847{#
|007d014045000054000040004001e6420a326e010a32d2010800302bd60d000101b1f74b0000000033f6060000000000101112131415161718191a1b
1c1d1e1f202122232425262728292a2b2c2d2e2f303132333435363799}
May 22 06:25:05 FEON kernel: MPLS mpls_skb_dump: from eth1 with len 88
(360)headroom=76 tailroom=28
May 22 06:25:05 FEON kernel:
003877360188ffff081077360188ffff081077360188ffff00000000010000004032540200eaffff00000000000000000000000001000000010000000000000000
1077360188ffff08207736{|003e814045000054b3300000400173120a32d201#0a326e010000382bd60d000101b1f74b0000000033f60600000000001011
12131415161718191a1b1c1d1e1f202122232425262728292a2b2c2d2e2f303132333435363700}
NETPERF SERVERSIDE
TESTS-------------------------------------------------------------------------------
NETPERF SERVERSIDE
TESTS-------------------------------------------------------------------------------
NETPERF SERVERSIDE
TESTS-------------------------------------------------------------------------------
May 22 06:25:33 FEON kernel: MPLS mpls_skb_dump: from eth1 with len 64
(1832)headroom=48 tailroom=1488
May 22 06:25:33 FEON kernel:
0080a6340188ffff505ca30000000005ffff1f00000100000e00ffff010700002020*00051b
70e93700051b00475e8847{#|007d01404500003c045240004006e2030a326e010a32d201c14032411226796400000000a00216d
0e0800000020405b40402080a00067d36000000000103030732}
May 22 06:25:33 FEON kernel: MPLS mpls_skb_dump: from eth1 with len 64
(552)headroom=240 tailroom=16
May 22 06:25:33 FEON kernel:
00b0f9340188ffff050200001f00000012020000061d0b00000000000100000058b1540200eaf
fff00000000000000000000000001000000010000000000000001000000000000000000000000000000000000000000000000b1540
200eaffff0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000008010000000625b8{|003e81404500003c000
040004006e6550a32d201#0a326e013241c1401154b13412267965a01216a093550000020405b40402080a00068abb00067d360103030700}
May 22 06:25:33 FEON kernel: MPLS mpls_skb_dump: from eth1 with len 56
(1832)headroom=48 tailroom=1496
May 22 06:25:33 FEON kernel:
00a0a6340188ffff505ca30000000005ffff1f00000100000e00ffff010700002020*00051b70e9370
0051b00475e8847{#|007d014045000034045340004006e20a0a326e010a32d201c1403241122679651154b1358010002ed88f00000101
080a00067d3a00068abbcb}
May 22 06:25:33 FEON kernel: MPLS mpls_skb_dump: from eth1 with len 312
(1832)headroom=48 tailroom=1240
May 22 06:25:33 FEON kernel:
0080a6340188ffff30007374000062736f6e2f2e636f6e6669672f6d656e75732f73*00051b70e9370
0051b00475e8847{#|007d014045000134045440004006e1090a326e010a32d201c1403241122679651154b1358018002ed765000001010
80a00067d3c00068abb0000000affffffffffffffffffffffff0000000000000008000000000000000000000000000000000000000a0000
000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000016}
|
|
From: Ahsan T. <ahs...@gm...> - 2010-05-19 14:35:48
|
Hi,
So disabling debug everything is ok :). So i have another question: Below is
a debug trace
for one ping as seen on an MPLS enabled router. While sending an MPLS packet
the
MAC header (bold lettering) is incomplete, but while recieving an MPLS
packet the
MAC header is complete. Is this expected behaviour or am I interpreting it
wrongly ?
Thanks
Ahsan
[ 8276.558954] MPLS DEBUG net/mpls/mpls_output.c:289:mpls_output: enter
[ 8276.558957] MPLS DEBUG net/mpls/mpls_output.c:328:mpls_output: exit
[ 8276.558960] MPLS DEBUG net/mpls/mpls_output.c:153:mpls_output2: enter
[ 8276.558962] MPLS DEBUG net/mpls/mpls_output.c:171:mpls_output2: opcode
PUSH
[ 8276.558964] MPLS DEBUG net/mpls/mpls_opcode.c:118:mpls_push: enter
[ 8276.558966] MPLS DEBUG net/mpls/mpls_opcode.c:132:mpls_push: using gap
[ 8276.558968] MPLS DEBUG net/mpls/mpls_opcode.c:188:mpls_push: exit
[ 8276.558970] MPLS DEBUG net/mpls/mpls_output.c:171:mpls_output2: opcode
SET
[ 8276.558972] MPLS DEBUG net/mpls/mpls_opcode.c:992:mpls_out_op_set: enter
[ 8276.558974] MPLS DEBUG net/mpls/mpls_opcode.c:1008:mpls_out_op_set: exit
[ 8276.558976] MPLS DEBUG net/mpls/mpls_output.c:77:mpls_send: output device
= eth1
[ 8276.558978] MPLS mpls_skb_dump: from eth1 with len 88 (424)headroom=44
tailroom=60
[ 8276.649709]
179b0b000000000000000000000000003f160000000000002d6f000000000000fc66**
00093d12df0e00093d12*
{#|003e813f45000054000040003f01dc50c0a86e02c0a8700508004361742a000120ecf34b000000006468090000000000101112131415161718191a1b1c1d1e1f202122232425262728292a2b2c2d2e2f303132333435363700}
[ 8276.963969] MPLS DEBUG net/mpls/mpls_output.c:124:mpls_send: using
neighbour (ffff8800c9047380)
[ 8276.963977] MPLS DEBUG net/mpls/mpls_output.c:131:mpls_send: mpls_send
result 0
[ 8276.963979] MPLS DEBUG net/mpls/mpls_output.c:205:mpls_output2: exit
[ 8277.782838] MPLS DEBUG net/mpls/mpls_input.c:229:mpls_skb_recv: enter
[ 8277.782841] MPLS mpls_skb_dump: from eth1 with len 88 (424)headroom=48
tailroom=56
[ 8277.873549]
000000000c07ac0000093d12df0d080045000089b28840004011d8ac8b1396038b13*
*00093d12df0e00093d125ffe8847*
{#|007d013f450000542ac000003f01f190c0a87005c0a86e0200004b61742a000120ecf34b000000006468090000000000101112131415161718191a1b1c1d1e1f202122232425262728292a2b2c2d2e2f30313233343536376c}
[ 8278.196542] MPLS DEBUG net/mpls/mpls_input.c:60:mpls_input: enter
[ 8278.196543] MPLS DEBUG net/mpls/mpls_input.c:74:mpls_input:
labelspace=0,label=2000,exp=0,B.O.S=1,TTL=63
[ 8278.196548] MPLS DEBUG net/mpls/mpls_input.c:96:mpls_input: opcode POP
[ 8278.196550] MPLS DEBUG net/mpls/mpls_input.c:96:mpls_input: opcode PEEK
[ 8278.196552] MPLS DEBUG net/mpls/mpls_input.c:172:mpls_input: delivering
[ 8278.196559] MPLS DEBUG net/mpls/mpls_input.c:275:mpls_skb_recv: exit(0)
On Wed, May 19, 2010 at 3:30 PM, Jorge Boncompte [DTI2] <jo...@dt...>wrote:
> El 19/05/2010 15:27, Ahsan Tariq escribió:
> > Hi,
> >
> > Just a quick question: with the latest patches from jorge things work
> > fine but the ping
> > round trip time takes 800 ms via MPLS while without MPLS it takes around
> > 0.8 ms.
> > Is this the expected behaviour ?
>
> If you have the debug information enabled yes else no :)
>
> --
> ==============================================================
> Jorge Boncompte - Ingenieria y Gestion de RED
> DTI2 - Desarrollo de la Tecnologia de las Comunicaciones
> --------------------------------------------------------------
> C/ Abogado Enriquez Barrios, 5 14004 CORDOBA (SPAIN)
> Tlf: +34 957 761395 / FAX: +34 957 450380
> ==============================================================
> - Sin pistachos no hay Rock & Roll...
> - Without wicker a basket cannot be made.
> ==============================================================
>
>
|
|
From: Ahsan T. <ahs...@gm...> - 2010-05-19 13:28:06
|
Hi, Just a quick question: with the latest patches from jorge things work fine but the ping round trip time takes 800 ms via MPLS while without MPLS it takes around 0.8 ms. Is this the expected behaviour ? Thanks, Ahsan On Wed, May 19, 2010 at 12:45 PM, Chris Robson <Chr...@nr...>wrote: > > Never mind, darn junk mail filter broke again! > > > On 05/19/2010 06:35 AM, Chris Robson wrote: > > > Jorge, Ashan > > Was another patch sent out to fix the dropped packet problem? If so what? > > thanks > Chris > > On 05/19/2010 04:22 AM, Ahsan Tariq wrote: > > Hi, > > > Thanks, its working now. > > Ahsan > > On Tue, May 18, 2010 at 6:31 PM, Jorge Boncompte [DTI2] <jo...@dt...>wrote: > >> El 18/05/2010 17:50, Ahsan Tariq escribió: >> > Hi, >> > >> > I have also tested the new patch and there are no lock up problems but >> > the ip packet gets dropped after the label is popped >> > The debug trace is below : >> > >> > [ 19.721739] MPLS: version 1.963 >> > [ 19.759418] MPLS: protocol driver interface - <jl...@mi... >> > <mailto:jl...@mi...>> >> > [ 19.835020] MPLS: IPv4 over MPLS support >> > [ 20.406281] MPLS: IPv6 over MPLS support >> > [ 494.929061] MPLS DEBUG net/mpls/mpls_input.c:229:mpls_skb_recv: enter >> > [ 494.929065] MPLS mpls_skb_dump: from eth1 with len 88 >> > (424)headroom=48 tailroom=56 >> > [ 495.037702] MPLS DEBUG net/mpls/mpls_input.c:60:mpls_input: enter >> > [ 495.037703] MPLS DEBUG net/mpls/mpls_input.c:74:mpls_input: >> > labelspace=0,label=2000,exp=0,B.O.S=1,TTL=63 >> > [ 495.037708] MPLS DEBUG net/mpls/mpls_input.c:96:mpls_input: opcode >> POP >> > [ 495.037710] MPLS DEBUG net/mpls/mpls_input.c:130:mpls_input: dropped >> > [ 495.037712] MPLS DEBUG net/mpls/mpls_input.c:283:mpls_skb_recv: >> > exit(DROP) >> > >> >> Ok, with this patch in top of the other I think it should work. >> >> -- >> ============================================================== >> Jorge Boncompte - Ingenieria y Gestion de RED >> DTI2 - Desarrollo de la Tecnologia de las Comunicaciones >> -------------------------------------------------------------- >> C/ Abogado Enriquez Barrios, 5 14004 CORDOBA (SPAIN) >> Tlf: +34 957 761395 / FAX: +34 957 450380 >> ============================================================== >> - Sin pistachos no hay Rock & Roll... >> - Without wicker a basket cannot be made. >> ============================================================== >> >> >> ------------------------------------------------------------------------------ >> >> >> _______________________________________________ >> mpls-linux-devel mailing list >> mpl...@li... >> https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel >> >> > > ------------------------------------------------------------------------------ > > > > > _______________________________________________ > mpls-linux-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel > > > ------------------------------------------------------------------------------ > > > > > _______________________________________________ > mpls-linux-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel > > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > mpls-linux-devel mailing list > mpl...@li... > https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel > > |
|
From: Chris R. <Chr...@nr...> - 2010-05-19 10:46:16
|
Never mind, darn junk mail filter broke again! On 05/19/2010 06:35 AM, Chris Robson wrote: > > Jorge, Ashan > > Was another patch sent out to fix the dropped packet problem? If so what? > > thanks > Chris > > On 05/19/2010 04:22 AM, Ahsan Tariq wrote: >> Hi, >> >> >> Thanks, its working now. >> >> Ahsan >> >> On Tue, May 18, 2010 at 6:31 PM, Jorge Boncompte [DTI2] >> <jo...@dt... <mailto:jo...@dt...>> wrote: >> >> El 18/05/2010 17:50, Ahsan Tariq escribió: >> > Hi, >> > >> > I have also tested the new patch and there are no lock up >> problems but >> > the ip packet gets dropped after the label is popped >> > The debug trace is below : >> > >> > [ 19.721739] MPLS: version 1.963 >> > [ 19.759418] MPLS: protocol driver interface - >> <jl...@mi... <mailto:jl...@mi...> >> > <mailto:jl...@mi... <mailto:jl...@mi...>>> >> > [ 19.835020] MPLS: IPv4 over MPLS support >> > [ 20.406281] MPLS: IPv6 over MPLS support >> > [ 494.929061] MPLS DEBUG >> net/mpls/mpls_input.c:229:mpls_skb_recv: enter >> > [ 494.929065] MPLS mpls_skb_dump: from eth1 with len 88 >> > (424)headroom=48 tailroom=56 >> > [ 495.037702] MPLS DEBUG net/mpls/mpls_input.c:60:mpls_input: >> enter >> > [ 495.037703] MPLS DEBUG net/mpls/mpls_input.c:74:mpls_input: >> > labelspace=0,label=2000,exp=0,B.O.S=1,TTL=63 >> > [ 495.037708] MPLS DEBUG net/mpls/mpls_input.c:96:mpls_input: >> opcode POP >> > [ 495.037710] MPLS DEBUG net/mpls/mpls_input.c:130:mpls_input: >> dropped >> > [ 495.037712] MPLS DEBUG net/mpls/mpls_input.c:283:mpls_skb_recv: >> > exit(DROP) >> > >> >> Ok, with this patch in top of the other I think it should >> work. >> >> -- >> ============================================================== >> Jorge Boncompte - Ingenieria y Gestion de RED >> DTI2 - Desarrollo de la Tecnologia de las Comunicaciones >> -------------------------------------------------------------- >> C/ Abogado Enriquez Barrios, 5 14004 CORDOBA (SPAIN) >> Tlf: +34 957 761395 / FAX: +34 957 450380 >> ============================================================== >> - Sin pistachos no hay Rock & Roll... >> - Without wicker a basket cannot be made. >> ============================================================== >> >> ------------------------------------------------------------------------------ >> >> >> _______________________________________________ >> mpls-linux-devel mailing list >> mpl...@li... >> <mailto:mpl...@li...> >> https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel >> >> >> >> ------------------------------------------------------------------------------ >> >> >> >> >> _______________________________________________ >> mpls-linux-devel mailing list >> mpl...@li... >> https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel >> > > > ------------------------------------------------------------------------------ > > > > > _______________________________________________ > mpls-linux-devel mailing list > mpl...@li... > https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel > |
|
From: Chris R. <Chr...@nr...> - 2010-05-19 10:35:38
|
Jorge, Ashan Was another patch sent out to fix the dropped packet problem? If so what? thanks Chris On 05/19/2010 04:22 AM, Ahsan Tariq wrote: > Hi, > > > Thanks, its working now. > > Ahsan > > On Tue, May 18, 2010 at 6:31 PM, Jorge Boncompte [DTI2] > <jo...@dt... <mailto:jo...@dt...>> wrote: > > El 18/05/2010 17:50, Ahsan Tariq escribió: > > Hi, > > > > I have also tested the new patch and there are no lock up > problems but > > the ip packet gets dropped after the label is popped > > The debug trace is below : > > > > [ 19.721739] MPLS: version 1.963 > > [ 19.759418] MPLS: protocol driver interface - > <jl...@mi... <mailto:jl...@mi...> > > <mailto:jl...@mi... <mailto:jl...@mi...>>> > > [ 19.835020] MPLS: IPv4 over MPLS support > > [ 20.406281] MPLS: IPv6 over MPLS support > > [ 494.929061] MPLS DEBUG > net/mpls/mpls_input.c:229:mpls_skb_recv: enter > > [ 494.929065] MPLS mpls_skb_dump: from eth1 with len 88 > > (424)headroom=48 tailroom=56 > > [ 495.037702] MPLS DEBUG net/mpls/mpls_input.c:60:mpls_input: enter > > [ 495.037703] MPLS DEBUG net/mpls/mpls_input.c:74:mpls_input: > > labelspace=0,label=2000,exp=0,B.O.S=1,TTL=63 > > [ 495.037708] MPLS DEBUG net/mpls/mpls_input.c:96:mpls_input: > opcode POP > > [ 495.037710] MPLS DEBUG net/mpls/mpls_input.c:130:mpls_input: > dropped > > [ 495.037712] MPLS DEBUG net/mpls/mpls_input.c:283:mpls_skb_recv: > > exit(DROP) > > > > Ok, with this patch in top of the other I think it should work. > > -- > ============================================================== > Jorge Boncompte - Ingenieria y Gestion de RED > DTI2 - Desarrollo de la Tecnologia de las Comunicaciones > -------------------------------------------------------------- > C/ Abogado Enriquez Barrios, 5 14004 CORDOBA (SPAIN) > Tlf: +34 957 761395 / FAX: +34 957 450380 > ============================================================== > - Sin pistachos no hay Rock & Roll... > - Without wicker a basket cannot be made. > ============================================================== > > ------------------------------------------------------------------------------ > > > _______________________________________________ > mpls-linux-devel mailing list > mpl...@li... > <mailto:mpl...@li...> > https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel > > > > ------------------------------------------------------------------------------ > > > > > _______________________________________________ > mpls-linux-devel mailing list > mpl...@li... > https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel > |
|
From: Ahsan T. <ahs...@gm...> - 2010-05-19 08:22:51
|
Hi, Thanks, its working now. Ahsan On Tue, May 18, 2010 at 6:31 PM, Jorge Boncompte [DTI2] <jo...@dt...>wrote: > El 18/05/2010 17:50, Ahsan Tariq escribió: > > Hi, > > > > I have also tested the new patch and there are no lock up problems but > > the ip packet gets dropped after the label is popped > > The debug trace is below : > > > > [ 19.721739] MPLS: version 1.963 > > [ 19.759418] MPLS: protocol driver interface - <jl...@mi... > > <mailto:jl...@mi...>> > > [ 19.835020] MPLS: IPv4 over MPLS support > > [ 20.406281] MPLS: IPv6 over MPLS support > > [ 494.929061] MPLS DEBUG net/mpls/mpls_input.c:229:mpls_skb_recv: enter > > [ 494.929065] MPLS mpls_skb_dump: from eth1 with len 88 > > (424)headroom=48 tailroom=56 > > [ 495.037702] MPLS DEBUG net/mpls/mpls_input.c:60:mpls_input: enter > > [ 495.037703] MPLS DEBUG net/mpls/mpls_input.c:74:mpls_input: > > labelspace=0,label=2000,exp=0,B.O.S=1,TTL=63 > > [ 495.037708] MPLS DEBUG net/mpls/mpls_input.c:96:mpls_input: opcode POP > > [ 495.037710] MPLS DEBUG net/mpls/mpls_input.c:130:mpls_input: dropped > > [ 495.037712] MPLS DEBUG net/mpls/mpls_input.c:283:mpls_skb_recv: > > exit(DROP) > > > > Ok, with this patch in top of the other I think it should work. > > -- > ============================================================== > Jorge Boncompte - Ingenieria y Gestion de RED > DTI2 - Desarrollo de la Tecnologia de las Comunicaciones > -------------------------------------------------------------- > C/ Abogado Enriquez Barrios, 5 14004 CORDOBA (SPAIN) > Tlf: +34 957 761395 / FAX: +34 957 450380 > ============================================================== > - Sin pistachos no hay Rock & Roll... > - Without wicker a basket cannot be made. > ============================================================== > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > mpls-linux-devel mailing list > mpl...@li... > https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel > > |
|
From: Jorge B. [DTI2] <jo...@dt...> - 2010-05-18 16:31:18
|
El 18/05/2010 17:50, Ahsan Tariq escribió: > Hi, > > I have also tested the new patch and there are no lock up problems but > the ip packet gets dropped after the label is popped > The debug trace is below : > > [ 19.721739] MPLS: version 1.963 > [ 19.759418] MPLS: protocol driver interface - <jl...@mi... > <mailto:jl...@mi...>> > [ 19.835020] MPLS: IPv4 over MPLS support > [ 20.406281] MPLS: IPv6 over MPLS support > [ 494.929061] MPLS DEBUG net/mpls/mpls_input.c:229:mpls_skb_recv: enter > [ 494.929065] MPLS mpls_skb_dump: from eth1 with len 88 > (424)headroom=48 tailroom=56 > [ 495.037702] MPLS DEBUG net/mpls/mpls_input.c:60:mpls_input: enter > [ 495.037703] MPLS DEBUG net/mpls/mpls_input.c:74:mpls_input: > labelspace=0,label=2000,exp=0,B.O.S=1,TTL=63 > [ 495.037708] MPLS DEBUG net/mpls/mpls_input.c:96:mpls_input: opcode POP > [ 495.037710] MPLS DEBUG net/mpls/mpls_input.c:130:mpls_input: dropped > [ 495.037712] MPLS DEBUG net/mpls/mpls_input.c:283:mpls_skb_recv: > exit(DROP) > Ok, with this patch in top of the other I think it should work. -- ============================================================== Jorge Boncompte - Ingenieria y Gestion de RED DTI2 - Desarrollo de la Tecnologia de las Comunicaciones -------------------------------------------------------------- C/ Abogado Enriquez Barrios, 5 14004 CORDOBA (SPAIN) Tlf: +34 957 761395 / FAX: +34 957 450380 ============================================================== - Sin pistachos no hay Rock & Roll... - Without wicker a basket cannot be made. ============================================================== |
|
From: Ahsan T. <ahs...@gm...> - 2010-05-18 15:50:27
|
Hi, I have also tested the new patch and there are no lock up problems but the ip packet gets dropped after the label is popped The debug trace is below : [ 19.721739] MPLS: version 1.963 [ 19.759418] MPLS: protocol driver interface - <jl...@mi...> [ 19.835020] MPLS: IPv4 over MPLS support [ 20.406281] MPLS: IPv6 over MPLS support [ 494.929061] MPLS DEBUG net/mpls/mpls_input.c:229:mpls_skb_recv: enter [ 494.929065] MPLS mpls_skb_dump: from eth1 with len 88 (424)headroom=48 tailroom=56 [ 495.037702] MPLS DEBUG net/mpls/mpls_input.c:60:mpls_input: enter [ 495.037703] MPLS DEBUG net/mpls/mpls_input.c:74:mpls_input: labelspace=0,label=2000,exp=0,B.O.S=1,TTL=63 [ 495.037708] MPLS DEBUG net/mpls/mpls_input.c:96:mpls_input: opcode POP [ 495.037710] MPLS DEBUG net/mpls/mpls_input.c:130:mpls_input: dropped [ 495.037712] MPLS DEBUG net/mpls/mpls_input.c:283:mpls_skb_recv: exit(DROP) I am also testing by sending a ping. Ahsan On Tue, May 18, 2010 at 5:39 PM, Chris Robson <Chr...@nr...>wrote: > > Jorge > > A resending of the show commands used also retested just to make sure > this configuration fails, results still fail: > > HOST A.................. > > [root@FEON ~]# mpls nhlfe show > NHLFE entry key 0x00000002 mtu 1496 propagate_ttl > push gen 1000 set eth1 ipv4 10.50.1.2 (0 bytes, 0 pkts) > > [root@FEON ~]# mpls ilm show > ILM entry label gen 2000 labelspace 0 proto ipv4 > pop peek (3784 bytes, 43 pkts) > > [root@FEON ~]# mpls labelspace show > LABELSPACE entry dev lo labelspace -1 > LABELSPACE entry dev mpls0 labelspace -1 > LABELSPACE entry dev eth0 labelspace -1 > LABELSPACE entry dev eth1 labelspace 0 > LABELSPACE entry dev wlan0 labelspace -1 > LABELSPACE entry dev pan0 labelspace -1 > LABELSPACE entry dev virbr0 labelspace -1 > LABELSPACE entry dev tun1 labelspace -1 > LABELSPACE entry dev tun2 labelspace -1 > > [root@FEON ~]# mpls xc show > > [root@FEON ~]# ip route show > 10.50.110.0/24 via 10.50.1.2 dev eth1 mpls 0x2 > > > HOST B...................... > > [root@FARP ~]# mpls nhlfe show > NHLFE entry key 0x00000002 mtu 1496 propagate_ttl > push gen 2000 set eth1 ipv4 10.50.1.1 (3612 bytes, 43 pkts) > > [root@FARP ~]# mpls ilm show > ILM entry label gen 1000 labelspace 0 proto ipv4 > pop peek (0 bytes, 0 pkts) > > [root@FARP ~]# mpls xc show > > [root@FARP ~]# mpls labelspace show > LABELSPACE entry dev lo labelspace -1 > LABELSPACE entry dev mpls0 labelspace -1 > LABELSPACE entry dev eth0 labelspace -1 > LABELSPACE entry dev wlan0 labelspace -1 > LABELSPACE entry dev eth1 labelspace 0 > LABELSPACE entry dev pan0 labelspace -1 > LABELSPACE entry dev virbr0 labelspace -1 > LABELSPACE entry dev tun1 labelspace -1 > > [root@FARP ~]# ip route show > 10.50.210.0/24 via 10.50.1.1 dev eth1 mpls 0x2 > > > .................Chris > > > > Have you copy&pasted the configuration because it looks the same. > > > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > mpls-linux-devel mailing list > mpl...@li... > https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel > |
|
From: Chris R. <Chr...@nr...> - 2010-05-18 15:39:48
|
Jorge
A resending of the show commands used also retested just to make sure
this configuration fails, results still fail:
HOST A..................
[root@FEON ~]# mpls nhlfe show
NHLFE entry key 0x00000002 mtu 1496 propagate_ttl
push gen 1000 set eth1 ipv4 10.50.1.2 (0 bytes, 0 pkts)
[root@FEON ~]# mpls ilm show
ILM entry label gen 2000 labelspace 0 proto ipv4
pop peek (3784 bytes, 43 pkts)
[root@FEON ~]# mpls labelspace show
LABELSPACE entry dev lo labelspace -1
LABELSPACE entry dev mpls0 labelspace -1
LABELSPACE entry dev eth0 labelspace -1
LABELSPACE entry dev eth1 labelspace 0
LABELSPACE entry dev wlan0 labelspace -1
LABELSPACE entry dev pan0 labelspace -1
LABELSPACE entry dev virbr0 labelspace -1
LABELSPACE entry dev tun1 labelspace -1
LABELSPACE entry dev tun2 labelspace -1
[root@FEON ~]# mpls xc show
[root@FEON ~]# ip route show
10.50.110.0/24 via 10.50.1.2 dev eth1 mpls 0x2
HOST B......................
[root@FARP ~]# mpls nhlfe show
NHLFE entry key 0x00000002 mtu 1496 propagate_ttl
push gen 2000 set eth1 ipv4 10.50.1.1 (3612 bytes, 43 pkts)
[root@FARP ~]# mpls ilm show
ILM entry label gen 1000 labelspace 0 proto ipv4
pop peek (0 bytes, 0 pkts)
[root@FARP ~]# mpls xc show
[root@FARP ~]# mpls labelspace show
LABELSPACE entry dev lo labelspace -1
LABELSPACE entry dev mpls0 labelspace -1
LABELSPACE entry dev eth0 labelspace -1
LABELSPACE entry dev wlan0 labelspace -1
LABELSPACE entry dev eth1 labelspace 0
LABELSPACE entry dev pan0 labelspace -1
LABELSPACE entry dev virbr0 labelspace -1
LABELSPACE entry dev tun1 labelspace -1
[root@FARP ~]# ip route show
10.50.210.0/24 via 10.50.1.1 dev eth1 mpls 0x2
.................Chris
> Have you copy&pasted the configuration because it looks the same.
>
>
|
|
From: Chris R. <Chr...@nr...> - 2010-05-18 15:29:16
|
Jorge
Oops.... cut&pasted wrong show statement it should have been:
# ip route show
10.50.110.0/24 via 10.50.1.2 dev eth1 mpls 0x2
Also here is a debug dump, doesnt seem to show anything related......
kernel: MPLS mpls_skb_dump: from eth1 with len 88 (1832)headroom=48
tailroom=1464
Further, the ping from Host B is "ping -I 10.50.110.1 10.50.210.1"
Note also, with "ping 10.50.210.1" from Host B the results are the same
- no reply. Iptables is turned off so it isn't filters. Its like the
packet labels are getting popped and then the packet is dropped? More
hunting to do yet......
HERE is a wireshark dump from Host A of the receiving packet from Host
B's ping
No. Time Source Destination Protocol
Info
46 486.578136 10.50.110.1 10.50.210.1
ICMP Echo (ping) request
Frame 46 (102 bytes on wire, 102 bytes captured)
Ethernet II, Src: MagicCon_00:47:5e (00:05:1b:00:47:5e), Dst:
MagicCon_70:e9:37 (00:05:1b:70:e9:37)
MultiProtocol Label Switching Header, Label: 2000, Exp: 0, S: 1, TTL: 64
MPLS Label: 2000
MPLS Experimental Bits: 0
MPLS Bottom Of Label Stack: 1
MPLS TTL: 64
Internet Protocol, Src: 10.50.110.1 (10.50.110.1), Dst: 10.50.210.1
(10.50.210.1)
Internet Control Message Protocol
Type: 8 (Echo (ping) request)
Code: 0 ()
Checksum: 0x05d9 [correct]
Identifier: 0xa516
Sequence number: 12 (0x000c)
Data (56 bytes)
0000 a7 b0 f2 4b 00 00 00 00 ee 34 06 00 00 00 00 00 ...K.....4......
0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ................
0020 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f !"#$%&'()*+,-./
0030 30 31 32 33 34 35 36 37
...Chris
On 05/18/2010 11:03 AM, Jorge Boncompte [DTI2] wrote:
> El 18/05/2010 16:48, Chris Robson escribió:
>
>> Hi Jorge
>>
>> Good and bad news.
>>
>> Good news is the lock up is fixed. I can see, via wireshark and debug,
>> ping packets being received without the system locking.
>>
>> Bad news is, the reply is not going out. Although, I'm not sure the
>> back-to-back host configuration is correct so that maybe the reason.
>> ergo here is what is configured:
>>
>>
>> Host A: eth1 - 10.50.1.1/24
>> eth0:1 - 10.50.210.1/24
>> /sbin/mpls labelspace set dev eth1 labelspace 0
>> LSPKey=`/sbin/mpls nhlfe add key 0 instructions push gen
>> 1000 nexthop eth1 ipv4 10.50.1.2 | grep key | cut -c 17-26`
>> /sbin/ip route add 10.50.110.0/24 via 10.50.1.2 mpls $LSPKey
>> /sbin/mpls ilm add label gen 2000 labelspace 0
>>
>> Host B: eth1 - 10.50.1.2/24
>> eth0:1 - 10.50.110.1/24
>> /sbin/mpls labelspace set dev eth1 labelspace 0
>> LSPKey=`/sbin/mpls nhlfe add key 0 instructions push gen
>> 2000 nexthop eth1 ipv4 10.50.1.1 | grep key | cut -c 17-26`
>> /sbin/ip route add 10.50.210.0/24 via 10.50.1.1 mpls $LSPKey
>> /sbin/mpls ilm add label gen 1000 labelspace 0
>>
>> +++++++++++++++++++++++++++++++++++++++++++
>> +++++++++++++++++++++++++++++++++++++++++++
>> Host A configuration info:
>>
>> eth0 Link encap:Ethernet HWaddr 00:21:86:52:8D:E4
>> inet addr:10.128.112.6 Bcast:10.128.112.255 Mask:255.255.255.0
>> inet6 addr: fe80::221:86ff:fe52:8de4/64 Scope:Link
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:512 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:666 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:1000
>> RX bytes:70643 (68.9 KiB) TX bytes:84260 (82.2 KiB)
>> Memory:fa200000-fa220000
>>
>> eth0:1 Link encap:Ethernet HWaddr 00:21:86:52:8D:E4
>> inet addr:10.50.110.1 Bcast:10.50.110.255 Mask:255.255.255.0
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> Memory:fa200000-fa220000
>>
>> eth1 Link encap:Ethernet HWaddr 00:05:1B:00:47:5E
>> inet addr:10.50.1.2 Bcast:10.50.1.255 Mask:255.255.255.0
>> inet6 addr: fe80::205:1bff:fe00:475e/64 Scope:Link
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:19 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:31 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:1000
>> RX bytes:3469 (3.3 KiB) TX bytes:5209 (5.0 KiB)
>>
>> # mpls nhlfe show
>> NHLFE entry key 0x00000002 mtu 1496 propagate_ttl
>> push gen 2000 set eth1 ipv4 10.50.1.1 (0 bytes, 0 pkts)
>> # mpls ilm show
>> ILM entry label gen 1000 labelspace 0 proto ipv4
>> pop peek (0 bytes, 0 pkts)
>> # ip route show
>> 10.50.210.0/24 via 10.50.1.1 dev eth1 mpls 0x2
>>
> This is wrong... shouldn't it be 10.50.1.2?
>
>
>> ++++++++++++++++++++++++++++++++++++++++++++
>> ++++++++++++++++++++++++++++++++++++++++++++
>>
>> Host B configuration dump:
>>
>> eth0 Link encap:Ethernet HWaddr 00:21:86:52:8D:E4
>> inet addr:10.128.112.6 Bcast:10.128.112.255 Mask:255.255.255.0
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:947 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:1293 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:1000
>> RX bytes:141125 (137.8 KiB) TX bytes:156121 (152.4 KiB)
>> Memory:fa200000-fa220000
>>
>> eth0:1 Link encap:Ethernet HWaddr 00:21:86:52:8D:E4
>> inet addr:10.50.110.1 Bcast:10.50.110.255 Mask:255.255.255.0
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> Memory:fa200000-fa220000
>>
>> eth1 Link encap:Ethernet HWaddr 00:05:1B:00:47:5E
>> inet addr:10.50.1.2 Bcast:10.50.1.255 Mask:255.255.255.0
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:20 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:31 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:1000
>> RX bytes:3551 (3.4 KiB) TX bytes:5209 (5.0 KiB)
>>
>> # mpls nhlfe show
>> NHLFE entry key 0x00000002 mtu 1496 propagate_ttl
>> push gen 2000 set eth1 ipv4 10.50.1.1 (1260 bytes, 15 pkts)
>> [root@FARP ~]# mpls ilm show
>> ILM entry label gen 1000 labelspace 0 proto ipv4
>> pop peek (0 bytes, 0 pkts)
>>
> Have you copy&pasted the configuration because it looks the same.
>
>
|
|
From: <jl...@mi...> - 2010-05-18 15:18:25
|
Good stuff. I will apply to the main tree. You can see the latest code at: git://repo.or.cz/mpls-linux.git That tree contains a kernel patch for core changes (shim and exports) and then a src dir for compiling mpls modules outside the kernel. I've found this to be a much quicker development/testing cycle. On Tue, May 18, 2010 at 12:00:50PM +0200, Jorge Boncompte [DTI2] wrote: > El 18/05/2010 11:09, Jorge Boncompte [DTI2] escribió: > > El 18/05/2010 0:15, Chris Robson escribió: > >> > >> Ashan > >> > >> I'm currently trying to test this but having lock up problems. However, > >> I have cornered the problem to the following code snip. Note the > >> conditional compile statement. This maybe the cause of the x86_64 > >> system locking up, but (and a big but) it also locks up with my x86_32 > >> systems as well. Will be collecting more data tomorrow but if anyone > >> has any ideas I'm all ears. FYI, the lock up occurs when > >> mpls_opcode_peek is called from mpls_skb_recv(). > >> > >> int mpls_opcode_peek(struct sk_buff *skb) > >> { > >> u32 shim; > >> > >> #define CAN_WE_ASSUME_32BIT_ALIGNED 0 > >> #if CAN_WE_ASSUME_32BIT_ALIGNED > >> shim = ntohl(*((u32*)&skb->network_header)); > >> #else > >> memcpy(&shim,skb->network_header,sizeof(u32)); > >> shim = ntohl(shim); > >> #endif > >> > >> if (!(MPLSCB(skb)->flag)) { > >> MPLSCB(skb)->ttl = shim & 0xFF; > >> MPLSCB(skb)->flag = 1; > >> } > >> MPLSCB(skb)->bos = (shim >> 8 ) & 0x1; > >> MPLSCB(skb)->exp = (shim >> 9 ) & 0x7; > >> MPLSCB(skb)->label = (shim >> 12) & 0xFFFFF; > >> > >> return MPLS_RESULT_RECURSE; > >> } > > > > Ok, that rang a bell. The problem is that in arches with BITS_PER_LONG > 32, > > some of the members of the skbuff are not pointers (network_header, > > transport_header, ...) but offsets. > > > > I'll cook a patch and send it to you to test. > > > > Try this. Maybe it does not apply to your tree because it is against the > codebase i am cleaning off but it should be simple to resolve. > > > -- > ============================================================== > Jorge Boncompte - Ingenieria y Gestion de RED > DTI2 - Desarrollo de la Tecnologia de las Comunicaciones > -------------------------------------------------------------- > C/ Abogado Enriquez Barrios, 5 14004 CORDOBA (SPAIN) > Tlf: +34 957 761395 / FAX: +34 957 450380 > ============================================================== > - Sin pistachos no hay Rock & Roll... > - Without wicker a basket cannot be made. > ============================================================== > diff --git a/net/bridge/netfilter/ebt_mpls.c b/net/bridge/netfilter/ebt_mpls.c > index 109cf16..541c4be 100644 > --- a/net/bridge/netfilter/ebt_mpls.c > +++ b/net/bridge/netfilter/ebt_mpls.c > @@ -30,8 +30,8 @@ static int target(struct sk_buff *skb, unsigned int hooknr, > * set skb->network_header = skb->data, skb->network_header > * is where we put the MPLS shim > */ > - skb_push(skb, skb->data - skb->mac_header); > - skb->network_header = skb->data; > + skb_push(skb, skb->data - skb_mac_header(skb)); > + skb_reset_network_header(skb); > mpls_output_shim(skb, nhlfe); > > /* don't let anyone else use this frame */ > diff --git a/net/ipv4/mpls4.c b/net/ipv4/mpls4.c > index bff2c70..5e9c6a8 100644 > --- a/net/ipv4/mpls4.c > +++ b/net/ipv4/mpls4.c > @@ -104,7 +104,7 @@ static struct sk_buff *mpls4_build_icmp(struct sk_buff *skb, int type, > /* now where at the payload, for now we're > * assuming this is IPv4 > */ > - skb->network_header = skb->data; > + skb_reset_network_header(skb); > > /* buid a new skb, that will be big enough to hold > * a maximum of 576 bytes (RFC792) > diff --git a/net/mpls/mpls_opcode.c b/net/mpls/mpls_opcode.c > index a5e663f..369e458 100644 > --- a/net/mpls/mpls_opcode.c > +++ b/net/mpls/mpls_opcode.c > @@ -78,9 +78,9 @@ int mpls_opcode_peek(struct sk_buff *skb) > > #define CAN_WE_ASSUME_32BIT_ALIGNED 0 > #if CAN_WE_ASSUME_32BIT_ALIGNED > - shim = ntohl(*((u32 *)&skb->network_header)); > + shim = ntohl(*((u32 *)&skb_network_header(skb))); > #else > - memcpy(&shim, skb->network_header, sizeof(u32)); > + memcpy(&shim, skb_network_header(skb), sizeof(u32)); > shim = ntohl(shim); > #endif > > diff --git a/net/mpls/mpls_utils.c b/net/mpls/mpls_utils.c > index 9204d1d..f5d58be 100644 > --- a/net/mpls/mpls_utils.c > +++ b/net/mpls/mpls_utils.c > @@ -142,7 +142,7 @@ EXPORT_SYMBOL(mpls_label2key); > * @skb - the packet to work on > * > * assumes valid data in MPLSCB(skb)->popped_bos and that > - * that skb->network_header is pointing to a label in the MPLS shim > + * that skb_network_header(skb) is pointing to a label in the MPLS shim > * returns a unsigned char* which point to the first byte after the MPLS > * shim. > * > @@ -194,7 +194,7 @@ EXPORT_SYMBOL(mpls_find_payload); > > void mpls_skb_dump(struct sk_buff *sk) > { > - unsigned int i; > + unsigned long i; > > printk(KERN_DEBUG "MPLS mpls_skb_dump: from %s with len %d (%d)" > "headroom=%d tailroom=%d\n", > @@ -204,17 +204,17 @@ void mpls_skb_dump(struct sk_buff *sk) > skb_headroom(sk), > skb_tailroom(sk)); > > - for (i = (unsigned int)sk->head; i <= (unsigned int)sk->tail; i++) { > - if (i == (unsigned int)sk->data) > + for (i = (unsigned long)sk->head; i <= (unsigned long)sk->tail; i++) { > + if (i == (unsigned long)sk->data) > printk("{"); > - if (i == (unsigned int)sk->transport_header) > + if (i == (unsigned long)skb_transport_header(sk)) > printk("#"); > - if (i == (unsigned int)sk->network_header) > + if (i == (unsigned long)skb_network_header(sk)) > printk("|"); > - if (i == (unsigned int)sk->mac_header) > + if (i == (unsigned long)skb_mac_header(sk)) > printk("*"); > printk("%02x", *((unsigned char *)i)); > - if (i == (unsigned int)sk->tail) > + if (i == (unsigned long)sk->tail) > printk("}"); > } > printk("\n"); > ------------------------------------------------------------------------------ > > _______________________________________________ > mpls-linux-devel mailing list > mpl...@li... > https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel -- James R. Leu jl...@mi... |
|
From: Jorge B. [DTI2] <jo...@dt...> - 2010-05-18 15:04:06
|
El 18/05/2010 16:48, Chris Robson escribió: > > Hi Jorge > > Good and bad news. > > Good news is the lock up is fixed. I can see, via wireshark and debug, > ping packets being received without the system locking. > > Bad news is, the reply is not going out. Although, I'm not sure the > back-to-back host configuration is correct so that maybe the reason. > ergo here is what is configured: > > > Host A: eth1 - 10.50.1.1/24 > eth0:1 - 10.50.210.1/24 > /sbin/mpls labelspace set dev eth1 labelspace 0 > LSPKey=`/sbin/mpls nhlfe add key 0 instructions push gen > 1000 nexthop eth1 ipv4 10.50.1.2 | grep key | cut -c 17-26` > /sbin/ip route add 10.50.110.0/24 via 10.50.1.2 mpls $LSPKey > /sbin/mpls ilm add label gen 2000 labelspace 0 > > Host B: eth1 - 10.50.1.2/24 > eth0:1 - 10.50.110.1/24 > /sbin/mpls labelspace set dev eth1 labelspace 0 > LSPKey=`/sbin/mpls nhlfe add key 0 instructions push gen > 2000 nexthop eth1 ipv4 10.50.1.1 | grep key | cut -c 17-26` > /sbin/ip route add 10.50.210.0/24 via 10.50.1.1 mpls $LSPKey > /sbin/mpls ilm add label gen 1000 labelspace 0 > > +++++++++++++++++++++++++++++++++++++++++++ > +++++++++++++++++++++++++++++++++++++++++++ > Host A configuration info: > > eth0 Link encap:Ethernet HWaddr 00:21:86:52:8D:E4 > inet addr:10.128.112.6 Bcast:10.128.112.255 Mask:255.255.255.0 > inet6 addr: fe80::221:86ff:fe52:8de4/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:512 errors:0 dropped:0 overruns:0 frame:0 > TX packets:666 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:70643 (68.9 KiB) TX bytes:84260 (82.2 KiB) > Memory:fa200000-fa220000 > > eth0:1 Link encap:Ethernet HWaddr 00:21:86:52:8D:E4 > inet addr:10.50.110.1 Bcast:10.50.110.255 Mask:255.255.255.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > Memory:fa200000-fa220000 > > eth1 Link encap:Ethernet HWaddr 00:05:1B:00:47:5E > inet addr:10.50.1.2 Bcast:10.50.1.255 Mask:255.255.255.0 > inet6 addr: fe80::205:1bff:fe00:475e/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:19 errors:0 dropped:0 overruns:0 frame:0 > TX packets:31 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:3469 (3.3 KiB) TX bytes:5209 (5.0 KiB) > > # mpls nhlfe show > NHLFE entry key 0x00000002 mtu 1496 propagate_ttl > push gen 2000 set eth1 ipv4 10.50.1.1 (0 bytes, 0 pkts) > # mpls ilm show > ILM entry label gen 1000 labelspace 0 proto ipv4 > pop peek (0 bytes, 0 pkts) > # ip route show > 10.50.210.0/24 via 10.50.1.1 dev eth1 mpls 0x2 This is wrong... shouldn't it be 10.50.1.2? > > ++++++++++++++++++++++++++++++++++++++++++++ > ++++++++++++++++++++++++++++++++++++++++++++ > > Host B configuration dump: > > eth0 Link encap:Ethernet HWaddr 00:21:86:52:8D:E4 > inet addr:10.128.112.6 Bcast:10.128.112.255 Mask:255.255.255.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:947 errors:0 dropped:0 overruns:0 frame:0 > TX packets:1293 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:141125 (137.8 KiB) TX bytes:156121 (152.4 KiB) > Memory:fa200000-fa220000 > > eth0:1 Link encap:Ethernet HWaddr 00:21:86:52:8D:E4 > inet addr:10.50.110.1 Bcast:10.50.110.255 Mask:255.255.255.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > Memory:fa200000-fa220000 > > eth1 Link encap:Ethernet HWaddr 00:05:1B:00:47:5E > inet addr:10.50.1.2 Bcast:10.50.1.255 Mask:255.255.255.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:20 errors:0 dropped:0 overruns:0 frame:0 > TX packets:31 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:3551 (3.4 KiB) TX bytes:5209 (5.0 KiB) > > # mpls nhlfe show > NHLFE entry key 0x00000002 mtu 1496 propagate_ttl > push gen 2000 set eth1 ipv4 10.50.1.1 (1260 bytes, 15 pkts) > [root@FARP ~]# mpls ilm show > ILM entry label gen 1000 labelspace 0 proto ipv4 > pop peek (0 bytes, 0 pkts) Have you copy&pasted the configuration because it looks the same. -- ============================================================== Jorge Boncompte - Ingenieria y Gestion de RED DTI2 - Desarrollo de la Tecnologia de las Comunicaciones -------------------------------------------------------------- C/ Abogado Enriquez Barrios, 5 14004 CORDOBA (SPAIN) Tlf: +34 957 761395 / FAX: +34 957 450380 ============================================================== - Sin pistachos no hay Rock & Roll... - Without wicker a basket cannot be made. ============================================================== |
|
From: Chris R. <Chr...@nr...> - 2010-05-18 14:49:14
|
Hi Jorge
Good and bad news.
Good news is the lock up is fixed. I can see, via wireshark and debug,
ping packets being received without the system locking.
Bad news is, the reply is not going out. Although, I'm not sure the
back-to-back host configuration is correct so that maybe the reason.
ergo here is what is configured:
Host A: eth1 - 10.50.1.1/24
eth0:1 - 10.50.210.1/24
/sbin/mpls labelspace set dev eth1 labelspace 0
LSPKey=`/sbin/mpls nhlfe add key 0 instructions push gen
1000 nexthop eth1 ipv4 10.50.1.2 | grep key | cut -c 17-26`
/sbin/ip route add 10.50.110.0/24 via 10.50.1.2 mpls $LSPKey
/sbin/mpls ilm add label gen 2000 labelspace 0
Host B: eth1 - 10.50.1.2/24
eth0:1 - 10.50.110.1/24
/sbin/mpls labelspace set dev eth1 labelspace 0
LSPKey=`/sbin/mpls nhlfe add key 0 instructions push gen
2000 nexthop eth1 ipv4 10.50.1.1 | grep key | cut -c 17-26`
/sbin/ip route add 10.50.210.0/24 via 10.50.1.1 mpls $LSPKey
/sbin/mpls ilm add label gen 1000 labelspace 0
+++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++
Host A configuration info:
eth0 Link encap:Ethernet HWaddr 00:21:86:52:8D:E4
inet addr:10.128.112.6 Bcast:10.128.112.255 Mask:255.255.255.0
inet6 addr: fe80::221:86ff:fe52:8de4/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:512 errors:0 dropped:0 overruns:0 frame:0
TX packets:666 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:70643 (68.9 KiB) TX bytes:84260 (82.2 KiB)
Memory:fa200000-fa220000
eth0:1 Link encap:Ethernet HWaddr 00:21:86:52:8D:E4
inet addr:10.50.110.1 Bcast:10.50.110.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Memory:fa200000-fa220000
eth1 Link encap:Ethernet HWaddr 00:05:1B:00:47:5E
inet addr:10.50.1.2 Bcast:10.50.1.255 Mask:255.255.255.0
inet6 addr: fe80::205:1bff:fe00:475e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:19 errors:0 dropped:0 overruns:0 frame:0
TX packets:31 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3469 (3.3 KiB) TX bytes:5209 (5.0 KiB)
# mpls nhlfe show
NHLFE entry key 0x00000002 mtu 1496 propagate_ttl
push gen 2000 set eth1 ipv4 10.50.1.1 (0 bytes, 0 pkts)
# mpls ilm show
ILM entry label gen 1000 labelspace 0 proto ipv4
pop peek (0 bytes, 0 pkts)
# ip route show
10.50.210.0/24 via 10.50.1.1 dev eth1 mpls 0x2
++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++
Host B configuration dump:
eth0 Link encap:Ethernet HWaddr 00:21:86:52:8D:E4
inet addr:10.128.112.6 Bcast:10.128.112.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:947 errors:0 dropped:0 overruns:0 frame:0
TX packets:1293 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:141125 (137.8 KiB) TX bytes:156121 (152.4 KiB)
Memory:fa200000-fa220000
eth0:1 Link encap:Ethernet HWaddr 00:21:86:52:8D:E4
inet addr:10.50.110.1 Bcast:10.50.110.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Memory:fa200000-fa220000
eth1 Link encap:Ethernet HWaddr 00:05:1B:00:47:5E
inet addr:10.50.1.2 Bcast:10.50.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:20 errors:0 dropped:0 overruns:0 frame:0
TX packets:31 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3551 (3.4 KiB) TX bytes:5209 (5.0 KiB)
# mpls nhlfe show
NHLFE entry key 0x00000002 mtu 1496 propagate_ttl
push gen 2000 set eth1 ipv4 10.50.1.1 (1260 bytes, 15 pkts)
[root@FARP ~]# mpls ilm show
ILM entry label gen 1000 labelspace 0 proto ipv4
pop peek (0 bytes, 0 pkts)
...................Chris
On 05/18/2010 06:00 AM, Jorge Boncompte [DTI2] wrote:
> El 18/05/2010 11:09, Jorge Boncompte [DTI2] escribió:
>
>> El 18/05/2010 0:15, Chris Robson escribió:
>>
>>> Ashan
>>>
>>> I'm currently trying to test this but having lock up problems. However,
>>> I have cornered the problem to the following code snip. Note the
>>> conditional compile statement. This maybe the cause of the x86_64
>>> system locking up, but (and a big but) it also locks up with my x86_32
>>> systems as well. Will be collecting more data tomorrow but if anyone
>>> has any ideas I'm all ears. FYI, the lock up occurs when
>>> mpls_opcode_peek is called from mpls_skb_recv().
>>>
>>> int mpls_opcode_peek(struct sk_buff *skb)
>>> {
>>> u32 shim;
>>>
>>> #define CAN_WE_ASSUME_32BIT_ALIGNED 0
>>> #if CAN_WE_ASSUME_32BIT_ALIGNED
>>> shim = ntohl(*((u32*)&skb->network_header));
>>> #else
>>> memcpy(&shim,skb->network_header,sizeof(u32));
>>> shim = ntohl(shim);
>>> #endif
>>>
>>> if (!(MPLSCB(skb)->flag)) {
>>> MPLSCB(skb)->ttl = shim& 0xFF;
>>> MPLSCB(skb)->flag = 1;
>>> }
>>> MPLSCB(skb)->bos = (shim>> 8 )& 0x1;
>>> MPLSCB(skb)->exp = (shim>> 9 )& 0x7;
>>> MPLSCB(skb)->label = (shim>> 12)& 0xFFFFF;
>>>
>>> return MPLS_RESULT_RECURSE;
>>> }
>>>
>> Ok, that rang a bell. The problem is that in arches with BITS_PER_LONG> 32,
>> some of the members of the skbuff are not pointers (network_header,
>> transport_header, ...) but offsets.
>>
>> I'll cook a patch and send it to you to test.
>>
>>
> Try this. Maybe it does not apply to your tree because it is against the
> codebase i am cleaning off but it should be simple to resolve.
>
>
>
>
>
> ------------------------------------------------------------------------------
>
>
>
>
> _______________________________________________
> mpls-linux-devel mailing list
> mpl...@li...
> https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel
>
|
|
From: Jorge B. [DTI2] <jo...@dt...> - 2010-05-18 10:01:04
|
El 18/05/2010 11:09, Jorge Boncompte [DTI2] escribió:
> El 18/05/2010 0:15, Chris Robson escribió:
>>
>> Ashan
>>
>> I'm currently trying to test this but having lock up problems. However,
>> I have cornered the problem to the following code snip. Note the
>> conditional compile statement. This maybe the cause of the x86_64
>> system locking up, but (and a big but) it also locks up with my x86_32
>> systems as well. Will be collecting more data tomorrow but if anyone
>> has any ideas I'm all ears. FYI, the lock up occurs when
>> mpls_opcode_peek is called from mpls_skb_recv().
>>
>> int mpls_opcode_peek(struct sk_buff *skb)
>> {
>> u32 shim;
>>
>> #define CAN_WE_ASSUME_32BIT_ALIGNED 0
>> #if CAN_WE_ASSUME_32BIT_ALIGNED
>> shim = ntohl(*((u32*)&skb->network_header));
>> #else
>> memcpy(&shim,skb->network_header,sizeof(u32));
>> shim = ntohl(shim);
>> #endif
>>
>> if (!(MPLSCB(skb)->flag)) {
>> MPLSCB(skb)->ttl = shim & 0xFF;
>> MPLSCB(skb)->flag = 1;
>> }
>> MPLSCB(skb)->bos = (shim >> 8 ) & 0x1;
>> MPLSCB(skb)->exp = (shim >> 9 ) & 0x7;
>> MPLSCB(skb)->label = (shim >> 12) & 0xFFFFF;
>>
>> return MPLS_RESULT_RECURSE;
>> }
>
> Ok, that rang a bell. The problem is that in arches with BITS_PER_LONG > 32,
> some of the members of the skbuff are not pointers (network_header,
> transport_header, ...) but offsets.
>
> I'll cook a patch and send it to you to test.
>
Try this. Maybe it does not apply to your tree because it is against the
codebase i am cleaning off but it should be simple to resolve.
--
==============================================================
Jorge Boncompte - Ingenieria y Gestion de RED
DTI2 - Desarrollo de la Tecnologia de las Comunicaciones
--------------------------------------------------------------
C/ Abogado Enriquez Barrios, 5 14004 CORDOBA (SPAIN)
Tlf: +34 957 761395 / FAX: +34 957 450380
==============================================================
- Sin pistachos no hay Rock & Roll...
- Without wicker a basket cannot be made.
==============================================================
|
|
From: Jorge B. [DTI2] <jo...@dt...> - 2010-05-18 09:09:48
|
El 18/05/2010 0:15, Chris Robson escribió:
>
> Ashan
>
> I'm currently trying to test this but having lock up problems. However,
> I have cornered the problem to the following code snip. Note the
> conditional compile statement. This maybe the cause of the x86_64
> system locking up, but (and a big but) it also locks up with my x86_32
> systems as well. Will be collecting more data tomorrow but if anyone
> has any ideas I'm all ears. FYI, the lock up occurs when
> mpls_opcode_peek is called from mpls_skb_recv().
>
> int mpls_opcode_peek(struct sk_buff *skb)
> {
> u32 shim;
>
> #define CAN_WE_ASSUME_32BIT_ALIGNED 0
> #if CAN_WE_ASSUME_32BIT_ALIGNED
> shim = ntohl(*((u32*)&skb->network_header));
> #else
> memcpy(&shim,skb->network_header,sizeof(u32));
> shim = ntohl(shim);
> #endif
>
> if (!(MPLSCB(skb)->flag)) {
> MPLSCB(skb)->ttl = shim & 0xFF;
> MPLSCB(skb)->flag = 1;
> }
> MPLSCB(skb)->bos = (shim >> 8 ) & 0x1;
> MPLSCB(skb)->exp = (shim >> 9 ) & 0x7;
> MPLSCB(skb)->label = (shim >> 12) & 0xFFFFF;
>
> return MPLS_RESULT_RECURSE;
> }
Ok, that rang a bell. The problem is that in arches with BITS_PER_LONG > 32,
some of the members of the skbuff are not pointers (network_header,
transport_header, ...) but offsets.
I'll cook a patch and send it to you to test.
Regards,
Jorge
--
==============================================================
Jorge Boncompte - Ingenieria y Gestion de RED
DTI2 - Desarrollo de la Tecnologia de las Comunicaciones
--------------------------------------------------------------
C/ Abogado Enriquez Barrios, 5 14004 CORDOBA (SPAIN)
Tlf: +34 957 761395 / FAX: +34 957 450380
==============================================================
- Sin pistachos no hay Rock & Roll...
- Without wicker a basket cannot be made.
==============================================================
|
14 messages has been excluded from this view by a project administrator.
