Nsis_Imp

nsis_imp@informatik.uni-goettingen.de

264 discussions

Bug report - nsis-0.5.1-dev
by Janusz Gozdecki 08 Nov '07

08 Nov '07

Dear All, I have fixed the previously reported bug: for IPv6 reservations the routers on the path do not process the QoSNSLP messages: The first part of required fix I have obtained from Fabio and Alexandre form IT Aveiro: nsis-0.5.1-dev/library/socket/UDPSocket.cpp – line 96: Old Code: rao[3] = 0x00; New code: rao[3] = 0x01; nsis-0.5.1-dev/gist/sockets/GistRawSockets.cpp – line 293: Old code: if (rao[0] == 0x05 && rao[1] == 0x02 && rao[2] == 0x00 && rao[3] == 0x00) { New code: if (rao[0] == 0x05 && rao[1] == 0x02 && rao[2] == 0x00 && rao[3] == 0x01) { This operation permits redefine the Router Alert Option used to send and receive the GIST-Query message. The second part: I have found a bug in isIPv6AddrInList() function which always reports that the address is in list, so the first router becomes always the QoSNSLP QNR and a message is not forwarded to a destination node (like in case the Scope flag is set). Below you find the proposed solution of the bug: Patch to nsis-0.5.1-dev/library/IPaddr.cpp: 124c124 < bool isIPv6AddrInList(unsigned char * addr, IPaddr * addrList, int addrCount, int prefix) --- > bool isIPv6AddrInList(unsigned char * addr, IPaddr * addrList, int addrCount, int prefix_org) 125a126 > 129a131 > int prefix = prefix_org; Best regards, Janusz

1 0

NSIS on an embedded platform
by Bertrand Goareguer 16 Oct '07

16 Oct '07

Hi, I've just ported NSIS 0.5.1-dev to an embedded device (big endian architecture) and I went through a few bugs: 1- It did not compile with uClibc because the file ifaddrs.h was missing. This is a file from the Glibc. Looking at the code, it only concerns the functions dealing with reading the system routing table (instead of taking it from the configuration file). So I just removed everything related to these functions and the problem was solved. 2- I haven't got OpenSSL yet on my board. The configure script detects that the library is missing, but there is a compilation error in the GistMAEntry.cpp file. The concerned functions are GistMAEntry::bindTCP and GistMAEntry::setSock. I managed to get rid of the problem by adding the preprocessor check "ifdef OPENSSL_FOUND" at those 2 places. If OpenSSL was not found, I just deleted everything related to TCPTLSSocket. 3- When communicating with an NSIS aware router (in fact, a Linux PC configured as a router with the NSIS implementation) the messages are received but the bandwidths are all set to 0. 4- The SID field of the messages received on the board are correct but the SID in the RESPONSE message (sent from the board to the router) are no the same (00040004 00040004 00040004 00040004 in the RESERVE becomes 00040001 00040004 00040004 00040004 in the RESPONSE). I saw that there was an implementation for OpenWrt, but this seems to be a package file. Would it be possible to get the sources ? Regards, Bertrand

1 2

NAT/FW NSLP question
by sunjinshan 09 Oct '07

09 Oct '07

Dear all, I have some problems in testing the NAT/FW NSLP.My testbed has 3 nodes[NI/NF/NR]and I want to create pinholes in the NF using the command shown below.But after runing the command,I got no response and the iptables rule didn't be configured. ./nsis-natfw --create -s 192.168.1.1 -d 172.16.0.1 --sport 5624 --dport 4612 --debug 0 NI NF NR 192.168.1.1-------192.168.1.2/172.16.0.2------172.16.0.1 I have tested the ping tool(using ./nsis-ping 172.16.0.1) and the Diagnostics NSLP（using ./nsis-diag 172.16.0.1）at NI,and they have no problem.The NSIS version is nsis-0.5.1-dev and the OS is FC3. I got the following results at the nodes using ethereal. NI Source Destination protocol Info 192.168.1.1 172.16.0.1 GIST GIST Query(UDP) 192.168.1.2 192.168.1.1 GIST GIST Response(UDP) 192.168.1.1 192.168.1.2 GIST GIST Confirm(TCP) 192.168.1.1 192.168.1.2 NAT/FW GIST Data(TCP) 192.168.1.1 192.168.1.2 GIST GIST MA-Hello(TCP) 192.168.1.2 192.168.1.1 GIST GIST MA-Hello(TCP) ...... NF(192.168.1.2) Source Destination protocol Info 192.168.1.1 192.168.1.2 GIST GIST Query(UDP) 192.168.1.2 192.168.1.1 GIST GIST Response(UDP) 192.168.1.1 172.16.0.1 GIST GIST Query(UDP) 192.168.1.2 192.168.1.1 GIST GIST Response(UDP) 192.168.1.1 192.168.1.2 GIST GIST Confirm(TCP) 192.168.1.1 192.168.1.2 NAT/FW GIST Data(TCP) 192.168.1.1 192.168.1.2 GIST GIST MA-Hello(TCP) 192.168.1.2 192.168.1.1 GIST GIST MA-Hello(TCP) ...... NF(172.16.0.2) Source Destination protocol Info 172.16.0.2 172.16.0.1 GIST GIST Query(UDP) 172.16.0.1 172.16.0.2 GIST GIST Response(UDP) 172.16.0.2 172.16.0.1 GIST GIST Confirm(TCP) 172.16.0.2 172.16.0.1 NAT/FW GIST Data(TCP) 172.16.0.2 172.16.0.1 GIST GIST MA-Hello(TCP) 172.16.0.1 172.16.0.2 GIST GIST MA-Hello(TCP) ...... Can anyone help me ? thank you . sunjinshan 2007-10-08 ---------------------------------------------------------------------------------------------- Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) is intended only for the use of the intended recipient and may be confidential and/or privileged of Neusoft Group Ltd., its subsidiaries and/or its affiliates. If any reader of this communication is not the intended recipient, unauthorized use, forwarding, printing, storing, disclosure or copying is strictly prohibited, and may be unlawful. If you have received this communication in error, please immediately notify the sender by return e-mail, and delete the original message and all copies from your system. Thank you. -----------------------------------------------------------------------------------------------

2 1

NAT/FW NSLP question
by sunjinshan 08 Oct '07

08 Oct '07

1 0

NAT/FW NSLP question
by sunjinshan 08 Oct '07

08 Oct '07

1 0

QoS NSLP bug in qspec objects
by Janusz Gozdecki 24 Sep '07

24 Sep '07

Hi all, I found following bug in QoS NSLP version 0.5.1-dev: The last four bytes of qspec objects , like Tmod1 and so on, is not copied properly using following constructor, so e.g. in case of Tmod1 object the minimum_unit1 parameter has a random value. I propose following fix: Old code: --------------------------------------------------------------- Tmod1::Tmod1(unsigned char *_buffer, unsigned int length) { tail=buffer; memcpy(buffer, _buffer, length); tail += 20; analyze(buffer+4, length-4); } ----------------------------------------------------------------- Fixed code: ----------------------------------------------------------------- Tmod1::Tmod1(unsigned char *_buffer, unsigned int length) { tail=buffer; memcpy(buffer, _buffer, length+4); tail += 20; analyze(buffer+4, length); } ---------------------------------------------------------------- Please note that all qspec objects should be modified in the above way. Another option to fix the bug is to modify function: void QspecObject::analyze(unsigned char * buffer, unsigned int length) in the following way: Line 184: obj_size = paramheader.length()*4; change to: obj_size = (paramheader.length()+1)*4; Best regards Janusz

2 1

IPv6 and 0.5.1-dev
by Eraldo Silveira e Silva 20 Sep '07

20 Sep '07

Hi all, I have configured 3 uml machines using 2.6.21 kernel with IPv6 as follows: A B C (2000:a::1)---------(2000:a::2) / \ (2000:b::1)--------------(2000:b::3) I can ping6 from A in B or C. I installed nsis 0.5.1-dev with gist, qos, diag and ping deamons in ALL machines. I setup nsis.conf in each machine to read automatically routing table. When I nsis-ping from A to C I have: PingMessage: hops = 3; length = 76; version = 1; seq# = 0 Hop: 1190297360.444709 2000:a::1 Hop: 1190297360.450552 2000:b::3 Hop: 1190297360.452030 2000:a::1 It seems to miss B machine. Why? If I try a reservation towards C it seems reserve only in A and B. What lacks? Regards, Eraldo

1 0

Patch: libNslp.a related updates
by Gotthard, Petr 13 Sep '07

13 Sep '07

Hello, I found out that the latest nsis-dev needs the following updates: - the NslpApi.h newly includes TimerBase.h and IPaddr.h, but these files are neither installed with "make install" nor LGPL-ed as all the other files included in NslpApi.h - the new IPaddr.cpp needs to be included in the libNslp.a plus - two enums in api_def.h are ending with a comma, and my gcc reports this as an error (so I suggest to remove the trailing commas) If you agree, could you please apply the attached patch to your development tree? regards Petr

2 2

reciever initiated reservation
by Bertrand Goareguer 16 Aug '07

16 Aug '07

Hello, When doing a receiver initiated reservation, if the requested bandwidth is not available, the node receiving the QUERY message should send a RESPONSE message with a RII or RSN back along the path (see the QOS NSLP state machine). The flow in the program is as follows : QoSFsm::idle_rx_query QoSFsm::process_reserve QoSFsm::send_response In QoSFsm::send_response, both the RII and RSN appear to be NULL, hence a segmentation fault occurs when creating the new RSN based on the one that should have been received (msg_received->rsn). Can anyone confirm this error ? Does anybody have a solution to that ? Regards, Bertrand PS : sorry for the double post...

1 0

receiver initiated reservation
by Bertrand Goareguer 16 Aug '07

16 Aug '07

Hello, When doing a receiver initiated reservation, if the requested bandwidth is not available, the node receiving the QUERY message is supposed to send a RESPONSE message along the return path with a RII or a RSN. The flow in the program is

1 0

← Newer
1
2
3
4
5
6
7
...
27
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Nsis_Imp