Menu
▾
▴
circum-devel — Development and general discussion about Circumference
You can subscribe to this list here.
| 2009 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(12) |
|
From: Sebastien D. <sde...@ni...> - 2010-12-06 01:26:46
|
Hi Jan, Thank you for all your support! > 3: Well that is where the RFC at least gives a word on: "When Diameter > is run over SCTP [RFC4960], which allows connections to span multiple > interfaces". Not to mention though that I don't see the value of it > either, because the address is given in the src ip -- or, if one > does not like that argument, take this: it's not just SCTP that > can be run over multiple interfaces. > Since you seem to be on the DIME list too, it might make sense > bringing that up there. I think a rationale may be to allow the Diameter stack to store the remote addresses where reconnection should be attempted, independently of lower layer mechanisms (i.e. getting the remote address from IP header, SCTP association, or DNS, among others...). In any case, thank you for the changes! Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) |
|
From: Jan E. <je...@me...> - 2010-12-04 00:00:20
|
>
>>What is one supposed to answer with, 0xffffffff or a list of all
>>supported application IDs?
>
>You peer is probably not supposed to answer with 0xfffffff if it does
>not support relaying messages (and I believe Circum does not support
>this).
Not at this time. If you like to add it though, it's just a module away.
You take
EXPORT_SYMBOL struct circumd_module circum_module_data = {
.app_name = "WebAuth",
.app_id = 11000,
.init = webauth_init,
.packet = webauth_packet,
.exit = webauth_exit,
};
and use .app_name="relay or so", .app_id=0, which is the ID for
modules wanting to listen to everything, and have a .packet function
that forwards it somewhere.
I was not sure what ID to use for promiscous modules, so circumd/socket.c
just has
if (mod->app_id == 0 || mod->app_id == pkt->appl_id)
mod->packet(...)
Maybe that should have included || mod->app_id == 0xFFFFFFFF,
because with circum_module_data.app_id == 0, relaying is not
actually advertised. Hm.
|
|
From: Jan E. <je...@me...> - 2010-12-03 14:22:01
|
On Friday 2010-12-03 06:30, Sebastien Decugis wrote: > >Pursuing my interoperability test, I have a new problem with the CEA >answered by circum server. It does not conform to the ABNF defined in >RFC3588 (and rfc3588bis as well) that say that the following AVP are >required: >1. one Vendor-Id AVP (value 0 if no registered value exist) >2. one Product-Name AVP (free UTF-8 string IIUC) >3. at least one Host-IP-Address AVP (I must confess I don't understand >this requirement because I don't see the value of this AVP, but it is >there anyway) 3: Well that is where the RFC at least gives a word on: "When Diameter is run over SCTP [RFC4960], which allows connections to span multiple interfaces". Not to mention though that I don't see the value of it either, because the address is given in the src ip -- or, if one does not like that argument, take this: it's not just SCTP that can be run over multiple interfaces. Since you seem to be on the DIME list too, it might make sense bringing that up there. >Would you add the missing AVPs so that the message becomes conform to >the RFC? -- or tell me if it is a configuration issue on my side? >I did not check for CER issued by circum, the same issue may exist also. The CER was fine. Fixed, thanks. Jan |
|
From: Jan E. <je...@me...> - 2010-12-03 13:42:46
|
On Friday 2010-12-03 06:20, Sebastien Decugis wrote:
>Hello,
>
>I have a compilation error in minitest when trying to compile latest
>circum under Ubuntu Natty. The following patch fixes the issue. It
>seems that libtool has a different behavior on this platform for some
>reason. Since I think there is no harm in this patch, would you
>consider applying it?
>
>--- a/libcircum/Makefile.am
>+++ b/libcircum/Makefile.am
>@@ -28,7 +28,7 @@ minitest_CFLAGS = ${AM_CFLAGS} \
>-minitest_LDADD = libcircum.la
>+minitest_LDADD = libcircum.la ${libHX_LIBS}
In fact, this is required (GNU ld was made stricter recently; among it
is -Wl,--as-needed, though this did not seem to be the case here),
so it's applied.
|
|
From: Sebastien D. <sde...@ni...> - 2010-12-03 05:30:35
|
Hello again, Pursuing my interoperability test, I have a new problem with the CEA answered by circum server. It does not conform to the ABNF defined in RFC3588 (and rfc3588bis as well) that say that the following AVP are required: - one Vendor-Id AVP (value 0 if no registered value exist) - one Product-Name AVP (free UTF-8 string IIUC) - at least one Host-IP-Address AVP (I must confess I don't understand this requirement because I don't see the value of this AVP, but it is there anyway) Would you add the missing AVPs so that the message becomes conform to the RFC? -- or tell me if it is a configuration issue on my side? I did not check for CER issued by circum, the same issue may exist also. Thank you! Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) |
|
From: Sebastien D. <sde...@ni...> - 2010-12-03 05:21:01
|
Hello,
I have a compilation error in minitest when trying to compile latest
circum under Ubuntu Natty.
The following patch fixes the issue. It seems that libtool has a
different behavior on this platform for some reason. (I also tested on
Debian and it compiled successfully without the patch). Since I think
there is no harm in this patch, would you consider applying it?
Thank you,
Best regards,
Sebastien.
diff --git a/libcircum/Makefile.am b/libcircum/Makefile.am
index d11b018..e8cef62 100644
--- a/libcircum/Makefile.am
+++ b/libcircum/Makefile.am
@@ -28,7 +28,7 @@ minitest_CFLAGS = ${AM_CFLAGS} \
-DPC_PKGLIBDIR=\"${pkglibdir}\" \
-DPC_PKGLIBEXECDIR=\"${pkglibexecdir}\" \
-DPC_PKGCONFIGDIR=\"${pkgconfigdir}\"
-minitest_LDADD = libcircum.la
+minitest_LDADD = libcircum.la ${libHX_LIBS}
noinst_MANS = minitest.8
--
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)
|
|
From: Sebastien D. <sde...@ni...> - 2010-12-03 04:58:46
|
Hello again Jan, > Though that does not quite strike me as the penultimate solution > for when the CEA sender has a huge list of available app ids, and > the CER sender is not a relay. If the remote peer is not a relay, I think it is OK to send only the result of the intersection if you prefer to keep the message as short as possible... > I pushed the change to git that causes CE to reply with all IDs. > Please test. Thank you! The issues I reported are now fixed. However, I am encountering new issues, I will send a separate mail. Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) |
|
From: Jan E. <je...@me...> - 2010-12-03 03:52:42
|
On Friday 2010-12-03 03:10, Sebastien Decugis wrote: > >> The RFC leaves some open questions, even if just non-normative. >I agree :) In my opinion it makes sense to reply with all the locally >supported applications when the remote peer advertises the Relay >application, so that this relay knows which messages can be routed to >this peer. Though that does not quite strike me as the penultimate solution for when the CEA sender has a huge list of available app ids, and the CER sender is not a relay. >- Circum returns an error NO_COMMON_APPLICATION, but RFC3588 (and bis) >explicitely says that if the CER contains the Relay application (value >0xffffffff), a common application is assumed: I pushed the change to git that causes CE to reply with all IDs. Please test. Jan |
|
From: Sebastien D. <sde...@ni...> - 2010-12-03 02:10:31
|
Hello Jan, Thank you for your answer. > The RFC leaves some open questions, even if just non-normative. I agree :) In my opinion it makes sense to reply with all the locally supported applications when the remote peer advertises the Relay application, so that this relay knows which messages can be routed to this peer. In any case, if you consider the Relay application as a kind of wildcard, the intersection of your local application list with this wildcard would give the same list as a result, which gives the expected result. But I guess the RFC leaves space for other interpretations here. > What is one supposed to answer with, 0xffffffff or a list of all supported > application IDs? You peer is probably not supposed to answer with 0xfffffff if it does not support relaying messages (and I believe Circum does not support this). The list of all locally supported applications makes more sense IMHO. > Speaking of which, the RFC is also somewhat unclear for non-relay > cases: > > *Either* I am supposed to send the intersection list (because /just > computing/ it without using it seems pretty pointless), or the list > of all supported apps, and let the CEA receiver deal with finding the > intersection. In my understanding, you compute the intersection just so that you determine if there is at least one common application. Sending back the result of the intersection, or the complete list of local applications, will not have any effect on the remote peer at the moment. It might change if the Capability-Update application is implemented, however. So, just to stay on the safe side, I would send the full list of local applications -- but this is only my personal interpretation, you may disagree ^^. Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) |
|
From: Jan E. <je...@me...> - 2010-12-02 14:36:12
|
On Tuesday 2010-11-30 02:44, Sebastien Decugis wrote: > >I am trying to establish a testbed as follow: >circum WebAuth client <--(B)--> freeDiameter relay <--(A)--> circum >WebAuth server. > >Now, I can get the freeDiameter relay to connect to the server. However, >the CER/CEA exchange fails. > >I see two problems in circum: > >- Circum returns an error NO_COMMON_APPLICATION, but RFC3588 (and bis) >explicitely says that if the CER contains the Relay application (value >0xffffffff), a common application is assumed: > >" Note that receiving a CER or CEA from a peer > advertising itself as a Relay (see Section 2.4 <http://tools.ietf.org/html/draft-ietf-dime-rfc3588bis-25#section-2.4>) MUST be interpreted > as having common applications with the peer." The RFC leaves some open questions, even if just non-normative. What is one supposed to answer with, 0xffffffff or a list of all supported application IDs? Speaking of which, the RFC is also somewhat unclear for non-relay cases: """The receiver of the [...] (CER) MUST [... compute] the intersection [...]. The sender of the [...] (CEA) SHOULD include all of its supported applications[...].""" *Either* I am supposed to send the intersection list (because /just computing/ it without using it seems pretty pointless), or the list of all supported apps, and let the CEA receiver deal with finding the intersection. >- When the CEA with the error code is sent, the Hop-by-hop id of the >message is not set to the same value as the request as it should, so it >is dropped by the remote peer. Fixed this in git, thanks. Jan |
|
From: Sebastien D. <sde...@ni...> - 2010-12-01 04:20:33
|
Hello, > Do you have configuration files for freediameter available > that I can just reuse? Sure! The flags I use to compile freeDiameter are in [1]. The configuration file is [2]. You'll probably have to change some paths in the file. Please let me know if you need additional information. [1] http://aaa.koganei.wide.ad.jp/hg/fD-testbed/file/tip/conf/fdrelay.iop.testbed.aaa/freeDiameter/CMakeFlags [2] http://aaa.koganei.wide.ad.jp/hg/fD-testbed/file/tip/conf/fdrelay.iop.testbed.aaa/freeDiameter/freeDiameter.conf Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) |
|
From: Jan E. <je...@me...> - 2010-12-01 03:34:10
|
On Tuesday 2010-11-30 02:44, Sebastien Decugis wrote: > >I am trying to establish a testbed as follow: >circum WebAuth client <--(B)--> freeDiameter relay <--(A)--> circum >WebAuth server. > >Now, I can get the freeDiameter relay to connect to the server. However, >the CER/CEA exchange fails. > >I see two problems in circum: [...] Do you have configuration files for freediameter available that I can just reuse? Jan |
|
From: Sebastien D. <sde...@ni...> - 2010-11-30 02:02:03
|
Hello, I am trying to establish a testbed as follow: circum WebAuth client <--(B)--> freeDiameter relay <--(A)--> circum WebAuth server. First of all, while trying to compile circum under Ubuntu Maverick, I encountered an issue that I reported under the bug tracker: http://sourceforge.net/tracker/?func=detail&aid=3122026&group_id=234453&atid=1092996 Now, I can get the freeDiameter relay to connect to the server. However, the CER/CEA exchange fails. I see two problems in circum: - Circum returns an error NO_COMMON_APPLICATION, but RFC3588 (and bis) explicitely says that if the CER contains the Relay application (value 0xffffffff), a common application is assumed: " Note that receiving a CER or CEA from a peer advertising itself as a Relay (see Section 2.4 <http://tools.ietf.org/html/draft-ietf-dime-rfc3588bis-25#section-2.4>) MUST be interpreted as having common applications with the peer." - When the CEA with the error code is sent, the Hop-by-hop id of the message is not set to the same value as the request as it should, so it is dropped by the remote peer. I believe both issues can be fixed quite easily. Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) |
|
From: Jan E. <je...@me...> - 2009-03-10 03:47:14
|
Greetings! RFC3588bis was recently updated to version 16, deprecating the Inband-Security-Id AVP and bumping the Diameter protocol version to 2. The Circumference 1.2 release implements these. Links: (tarball) http://downloads.sf.net/circum/circumference-1.2.tar.bz2 (gitweb) http://circum.git.sf.net/ (clone) git://circum.git.sf.net/gitroot/circum Changelog: v1.2 (March 10 2009) ==================== - implement changes stemming from RFC3588bis16 update: - remove Inband-Security-Id AVP from libcircum output - bump Diameter protocol version to 2 |
