Nsis_Imp April 2007

nsis_imp@informatik.uni-goettingen.de

7 participants
7 discussions

error on creating reservation
by Fábio 28 Apr '07

28 Apr '07

Hi, I applied that patch (qos_2006-12-30.tar.gz) on all nodes, but i still can't make this work. This time I attached the qni and the qne logs. The problem is the following: On the 145th line of file "log_qne_nsis" we can see that the program tries to delete a reservation that does not exist. QoSFsm::inst__timeout_statelifetime() Refresh Timer stoped State Timer stoped Releasing reservation ... Traffic Number is 0 ... (IpTables) Running "iptables -t mangle -D PREROUTING -j MARK --set-mark 0x0000" iptables: No chain/target/match by that name as a result of this, on the qni the program stuck on QoSFsm::response_timeout() triggerEvent : ST_IDLE::EV_TIMEOUT_WAITRESP (err) Event (6) not specified for current state (0) until eventually it reaches timeout. ** Process 19525 got signal 11: SIGSEGV *** Unix Socket: Connection reset by peer *** I don't know why this is happening. If someone could help me it would be fine. Thanks, Fabio

2 1

SimpleRMF problem
by Fábio 26 Apr '07

26 Apr '07

My name is Fabio. I'm making a project on NSIS signalling, using the NSIS-0.5.0-dev version on the following testbed: _____ _____ _____ _____ I A I___I B I___I C I___I D I I I I I I I I I ----- ----- ----- ----- where B and C are peers and A and D are ends. I can see this working (nsis-ping and nsis-qos) when i'm using NullRMF. However, when i try to use SimpleRMF it crashes. STEP 1- I configured (nsis.conf) A and D with NullRMF because they are ends. qos.rmf = NullRMF qos.simplermf.interfaces = eth0 qos.simplermf.interface[eth0].overall_bandwidth = 10mbit qos.simplermf.interface[eth0].min_unclassified_bandwidth = 100kbit qos.simplermf.interface[eth0].max_unclassified_bandwidth = 10mbit STEP 2- I configured (nsis.conf) B and C with SimpleRMF because they are peers. qos.rmf = SimpleRMF qos.simplermf.interfaces = eth0, eth1 qos.simplermf.interface[eth0].overall_bandwidth = 10mbit qos.simplermf.interface[eth1].overall_bandwidth = 10mbit qos.simplermf.interface[eth0].min_unclassified_bandwidth = 100kbit qos.simplermf.interface[eth1].min_unclassified_bandwidth = 100kbit qos.simplermf.interface[eth0].max_unclassified_bandwidth = 10mbit qos.simplermf.interface[eth1].max_unclassified_bandwidth = 10mbit STEP 3- I run ./nsis on A, B, C and D. STEP 4- I run ./nsis-qosd on D STEP 5- Then I run ./nsis-qos <IP_D> I also use Ethereal on all nodes and i can see that the problem is on B (the 1st router) because the reservation can't be made. The message I get on the ./nsis log in B is the following: (err) Using 10.0.0.1 as local IPv4 address (err) Using 192.168.0.1 as local IPv4 address (err) Using 192.168.0.1 as local IPv4 address (err) Using 2001:690:2380:777a:240:63ff:fedb:7411 as local IPv6 address (err) Using 2001:690:2380:7777:202:44ff:fe9c:806c as local IPv6 address NSIS daemon v0.5.0-dev starting ... My PID id = 8986 FD is -1 TEST: no Starting qosServer (pid: 8987) ... (TC) Running "tc qdisc delete dev eth0 root handle 1:" Starting diagServer (pid: 8988) ... (err) Diag: connected to GIST server (IpTables) Running "iptables -t mangle -F PREROUTING" (TC) Running "tc qdisc add dev eth0 root handle 1: htb default 2" (TC) Running "tc class add dev eth0 parent 1: classid 1:1 htb rate 10mbit burst 15k" (TC) Running "tc class add dev eth0 parent 1:1 classid 1:2 htb rate 100kbit ceil 10mbit" (TC) Running "tc qdisc add dev eth0 parent 1:2 handle 2: sfq perturb 10" (TC) Running "tc qdisc delete dev eth1 root handle 1:" (IpTables) Running "iptables -t mangle -F PREROUTING" (TC) Running "tc qdisc add dev eth1 root handle 1: htb default 2" (TC) Running "tc class add dev eth1 parent 1: classid 1:1 htb rate 10mbit burst 15k" (TC) Running "tc class add dev eth1 parent 1:1 classid 1:2 htb rate 100kbit ceil 10mbit" (TC) Running "tc qdisc add dev eth1 parent 1:2 handle 2: sfq perturb 10" QoSServer: connected to GIST server SID: ffffffff ffffffff ffffffff ffffffff >-- This is an unknown session!! --< fsm : (nil) We are Entity (QNE) QNE: --> incoming msg + srcAddr : 2001:690:2380:7777:211:2fff:fea6:644 + destAddr : 2001:690:2380:777c:20a:e4ff:fe03:73f5 + direction : DOWNSTREAM + msg length : 112 bytes + QoS Message Type : RESERVE + Object Type : RII ++ RII : 0x620cb7fe + Object Type : RSN ++ RSN : 1 ++ EpochID : 0x462ce38a + Object Type : PacketClassifier ++ PacketClassifier : 0x00 ++ PC-Flags : 0xc000 + Object Type : Qspec + QSPEC obj length : 19 ++ Qspec Version : 1 ++ QOSM ID : 1 ++ Message Seq. : 1 ++ Obj Combination : 1 +++ Object type : Minimum QoS, length:17 +++ Object type : ExcessTreatment, length:1 +++ Object type : Traffic, length:5 +++ Object type : QoSClass, length:3 +++ Object type : Priority, length:4 + Q:T:R:S-Flag : 1:0:0:0 triggerEvent : ST_IDLE::EV_RX_RESERVE QoSFsm::idle__rx_reserve() Reserving ... ** Process 8987 got signal 11: SIGSEGV *** Unix Socket: Connection reset by peer *** NslpApi::api_send() Bad file descriptor (nslp_api/unix_sockets.cpp:52) RecvMessage(): send failed. On the other hand, I get the folowing message in node A > Received response code 2 (failed) Concluding, it's obvious that the deamon crashes when i run the ./nsis-qos <IP_D> which means that it tries to establish the reservation before it crashes. I don't believe this is a bug, so i think it can be caused by a bad (??) configuration. Can anyone give me a clue on this ? best regards, Fábio Ferreira

2 5

Authentication in NatFw NSLP
by Prateek Gupta 24 Apr '07

24 Apr '07

Hi, I am implementing the AUTH_SESSION object ( http://tools.ietf.org/wg/nsis/draft-manner-nsis-nslp-auth-03.txt ) for NatFw NSLP. I am using the following set-up A(NI)-----B(FW)----------C(NR) I have been able to send AUTH_SESSION object from A to B, At B a radius/diameter message is to be generated using information extracted from the AUTH_SESSION object. Can somebody provide any help /reference regarding how to authenticate this auth object using radius/diameter? Regards, Prateek

2 1

g++ 4.1.2 compile
by Victor Fajardo 17 Apr '07

17 Apr '07

Hi, Attached is a short diff on g++ 4.1.2 compile problems for official nsis release 0.4.0. --- library/libxorp/eventloop.hh 2007-04-16 16:12:39.000000000 -0400 +++ library/libxorp/eventloop.hh 2007-04-16 16:12:57.000000000 -0400 @@ -224,9 +224,9 @@ * pending. * @return true on success. */ - inline bool EventLoop::add_selector(int fd, - SelectorMask mask, - const SelectorCallback& cb); + inline bool add_selector(int fd, + SelectorMask mask, + const SelectorCallback& cb); /** * Remove hooks associated with file descriptor. --- nslp/qos/QoSServer.h 2007-04-16 16:14:42.000000000 -0400 +++ nslp/qos/QoSServer.h 2007-04-16 16:15:01.000000000 -0400 @@ -95,7 +95,7 @@ static int compare(unsigned char *a, unsigned char *b); static void add_sid(unsigned char *sid, QoSFsm *fsm); - static QoSFsm *QoSServer::get_fsm_for_sid(unsigned char *sid); + static QoSFsm *get_fsm_for_sid(unsigned char *sid); static void delete_sid(unsigned char *sid); static unsigned int getRSN(); --- nslp/natfw/fsm/NatFwFsm.h 2007-04-16 16:16:29.000000000 -0400 +++ nslp/natfw/fsm/NatFwFsm.h 2007-04-16 16:17:16.000000000 -0400 @@ -57,7 +57,7 @@ ev_rx_create, ev_EOL }; - static const char * NatFwFsm::eventStr[]; + static const char * eventStr[]; // do not change manually, apply constants.xml enum States @@ -75,7 +75,7 @@ st_nr_reapending, st_EOL }; - static const char * NatFwFsm::stateStr[]; + static const char * stateStr[]; NatFwFsm(States state); virtual ~NatFwFsm() {}; --- nslp/natfw/NatFwServer.h 2007-04-16 16:17:38.000000000 -0400 +++ nslp/natfw/NatFwServer.h 2007-04-16 16:17:53.000000000 -0400 @@ -101,7 +101,7 @@ bool isLocalAddress(IPaddr addr); bool isLocalAddress(unsigned int addr); - int NatFwServer::SendMessage(NatFwFsmData * data); + int SendMessage(NatFwFsmData * data); int SendMessage(char *nslp_data, unsigned int nd_size, char *nslp_message_handle, unsigned short nslp_id, unsigned char sid[SID_SIZE], msg_routing_info_base_t *mri, char *source_s2_handle, best regards, victor

2 1

RE: [Nsis_imp] First data message lost using TCP
by Christian Dickmann 04 Apr '07

04 Apr '07

Hi, > I am currently working with your NSIS suite version 0.5.0-dev and > implemented my own NSLP. Everything works fine except of one small > problem using TCP as transport protocol. > When I start NSIS and my NSLP on two machines and try to send a message > from one machine to the other, the first GIST data message gets lost. > The message association of GIST is build up without problems (Query, > Response and Configure are sent). But the first data message doesn't > arrive at receiver side. All following data messages are received. I > captured this using ethereal. I encountered a problem like this before. It might be a problem of the current 0.5.0-dev and might already be fixed in our internal development version. We are going to release a new development snapshot soon and if you want, I can send you a preview copy to check if the new version fixes the problem. However, please note that the NSLP API was slightly modified, so you will need to adapt your NSLP ... (nothing dramatic) > > As I thought this has something to do with my NSLP implementation I > tested it with your Ping tool. When I start the ping tool sending pings > from one machine to the other, the first ping message is lost too (a > ping timeout is triggered for the first message). Following pings are > sent and received without any problem. > > Do you have any suggestions what is the reason for this ? Might there > be something wrong with my configuration (see below) ? > Thanks for your support in advance. I guess there is nothing wrong with your NSLP or configuration and if I remember correctly you really encountered a bug. Best regards, Christian Dickmann

1 0

First data message lost using TCP
by Andreas Deininger 04 Apr '07

04 Apr '07

Hello, I am currently working with your NSIS suite version 0.5.0-dev and implemented my own NSLP. Everything works fine except of one small problem using TCP as transport protocol. When I start NSIS and my NSLP on two machines and try to send a message from one machine to the other, the first GIST data message gets lost. The message association of GIST is build up without problems (Query, Response and Configure are sent). But the first data message doesn't arrive at receiver side. All following data messages are received. I captured this using ethereal. As I thought this has something to do with my NSLP implementation I tested it with your Ping tool. When I start the ping tool sending pings from one machine to the other, the first ping message is lost too (a ping timeout is triggered for the first message). Following pings are sent and received without any problem. Do you have any suggestions what is the reason for this ? Might there be something wrong with my configuration (see below) ? Thanks for your support in advance. Regards, Andreas Deininger My configuration is as follows: (same on both machines, except the IP address) # General configuration nslp.startPing = yes nslp.startQoS = no nslp.startNatFw = no nslp.startDiag = no gist.acceptExplicitMessages = yes gist.acceptStatelessGistMessage = yes # Transport configuration gist.offerSCTP = no gist.offerTLS = no gist.useSCTP = no # Timer configuration gist.timeout.waitForInitialResponse = 10000 gist.timeout.waitForConfirm = 10000 gist.timeout.refreshInterval = 30000 gist.timeout.queryingNodeStateExpiration = 100000 gist.timeout.respondingNodeStateExpiration = 100000 # Routing configuration IPv4.entries = 1 IPv4[0].addr = 10.30.30.1 #(10.30.30.2 on the other machine) IPv4[0].net = 10.30.30.0 IPv4[0].mask = 24 _______________________________________________________________ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192

1 0

RE: [Nsis_imp] NSIS 0.5.0-dev beta and IPv6
by Christian Dickmann 03 Apr '07

03 Apr '07

Hi all, I just completed testing the basic GIST operations using IPv6 and it works fine (using our latest internal development version). The problem described below was a bug of an outdated nsis-0.5.0-dev version, while the latest version on our webpage does not contain the bug anymore. Regards, Christian Dickmann -----Original Message----- From: Janusz Gozdecki [mailto:gozdecki@agh.edu.pl] Sent: Tuesday, March 27, 2007 10:21 AM To: Christian Dickmann Cc: Norbert Rapacz/KT AGH; nsis_imp(a)informatik.uni-goettingen.de Subject: Re: [Nsis_imp] NSIS 0.5.0-dev beta and IPv6 Dear Christian, Thank you for your fast response. Due to my college is out of office I will try to answer your questions. Please see inline: Christian Dickmann wrote: > Hi, > >> We are going to use NSIS Suite as a daemon for QOS-NSLP signalling in >> out >> project. We have tested version 0.4 and beta 0.5 and found that >> version 0.5 >> has some troubles with working with IPv6 (seems like daemon is not >> able to >> receive IPv6 packets � socket is not bound), while in version 0.4 it >> works >> fine. > > > Can you be more precise on which kinds of IPv6 packets are not > received? Are you referring to end-hosts or routers/forwarders or even > both? > In addition, can you tell me with which NSLP you did your testing? Did > you use the Ping tool or Diagnostics NSLP or directly the QoS NSLP? > I guess you tested on Linux? I am referring to end-hosts and routers in the beta 0.5 version. I have been testing both Ping tool and QoS NSLP on Linux (Ubuntu 6.06 LTS, gcc 4.03). In ethereal I see that sender sends IPv6 packets, but does not receives any response. I have roughly inspected source files and in the gist/Gist.cpp file noticed that in the function "Gist::setup_signaling_listeners()" there is the comment "// TODO: register callback" in IPv6 section. So, I assumed that the reception of incoming IPv6 packets is not implemented in this version - am I right? In IPv4 section of this function the registration of callback functions is implemented. By default USE_XORP is not defined in lib/constants.h. Thank you for help, Best regards, Janusz > >> >> My question is whether functionality of IPv6 is going to be fixed and >> supported in subsequent releases of NSIS Suite? We would like to use >> a newer >> version ;) > > > Up to now I was not aware that there is any problem. Of course, we > want to support IPv6 and if there is any bug in the current code, we > will fix it. I am currently in the process of preparing a thorough > testing of our GIST implementation, which also involves IPv6 support. > As soon as there is a new version available I will sent a note to this > mailing list. If the bug is minor, I might even provide a small patch > for you. > > Thank you for your interest and I hope we can help you with your problem. > > Regards, > Christian > > _______________________________________________ > Nsis_Imp mailing list > Nsis_Imp(a)informatik.uni-goettingen.de > https://user.informatik.uni-goettingen.de/mailman/listinfo/nsis_imp -- ------------------------------------------------------------------------------------------------- Janusz Gozdecki, M.Sc. AGH University of Science and Technology, Dept. of Telecommunications, al. Mickiewicza 30, 30-059 Krakow, Poland mailto:gozdecki@kt.agh.edu.pl Work: +48(12)6173599, Fax: +48(12)6342372

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Nsis_Imp April 2007