[CUWiN-Dev] Progress towards HSLS LInux Port [from Latest Code base]

Fri Mar 9 08:41:25 CST 2007

Dave;

Well I resolved the problem. Needless to say all my fault. Anyway it had to
do with queues.

Now from both the Laptop and the CUWiN box I can see(tcpdump) 9191 packets.

I start my port like : ./hslsd -d -c 127.0.0.1  -L all  -s /usr/zserv.api -f
inet -t stub -i eth0 -p 146.64.19.215/24 -f inet -t ptmp -i eth1

Problem is neither CUWiN nor Laptop updates the routes. At least I was
expecting to see 146.64.19.215 on the CUWiN box.

*********************************************************************************************************************
>From the Laptop:

lawrence at appletiser:~/work/latest_hsls$ sudo tcpdump -i eth1 -n port 9191

16:27:37.409272 IP 169.254.237.50.9191 > 224.0.0.2.9191: UDP, length 64
16:27:37.457141 IP 169.254.237.110.9191 > 224.0.0.2.9191: UDP, length 252
16:27:37.460935 IP6 fe80::202:6fff:fe20:ed6e.9191 > ff02::2.9191: UDP,
length 252
16:27:38.409658 IP 169.254.237.50.9191 > 224.0.0.2.9191: UDP, length 64
16:27:38.467258 IP 169.254.237.110.9191 > 224.0.0.2.9191: UDP, length 252
16:27:38.471079 IP6 fe80::202:6fff:fe20:ed6e.9191 > ff02::2.9191: UDP,
length 252

cuw-bootstrap> show ip rou
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
       I - ISIS, B - BGP, > - selected route, * - FIB route

K>* 0.0.0.0/0 via 146.64.19.30, eth0
C>* 127.0.0.0/8 is directly connected, lo
C>* 146.64.19.0/24 is directly connected, eth0
K>* 146.64.19.215/32 is directly connected, eth0
C>* 169.254.0.0/16 is directly connected, eth1
K>* 224.0.0.0/4 is directly connected, eth1
S>* 224.0.0.5/32 [1/0] via 127.0.0.1, lo
S>* 224.0.0.6/32 [1/0] via 127.0.0.1, lo
S>* 224.0.0.9/32 [1/0] via 127.0.0.1, lo
cuw-bootstrap> show ip rou
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
       I - ISIS, B - BGP, > - selected route, * - FIB route

**********************************************************************************************************************
CUWiN box:

# tcpdump -i ath0 port 9191
08:46:17.625681 fe80::202:6fff:fe20:ed6e.hsls > ff02::2.hsls: UDP, length:
252 [hlim 1]
08:46:17.638342 IP 169.254.237.50.hsls > 224.0.0.2.hsls: UDP, length: 64
08:46:17.694342 fe80::202:6fff:fe20:ed6e.hsls > ff02::2.hsls: UDP, length:
72 [hlim 1]
08:46:17.695224 IP 169.254.237.110.hsls > 224.0.0.2.hsls: UDP, length: 72
08:46:17.730488 IP 169.254.237.50.hsls > 224.0.0.2.hsls: UDP, length: 72
08:46:18.641797 IP 169.254.237.110.hsls > 224.0.0.2.hsls: UDP, length: 252
08:46:18.642353 IP 169.254.237.50.hsls > 224.0.0.2.hsls: UDP, length: 64
08:46:18.645975 fe80::202:6fff:fe20:ed6e.hsls > ff02::2.hsls: UDP, length:
252 [hlim 1]
08:46:19.646128 IP 169.254.237.50.hsls > 224.0.0.2.hsls: UDP, length: 68

cuw-bootstrap> show ip rout
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
       I - ISIS, B - BGP, > - selected route, * - FIB route

K>* 10.0.0.0/16 via 127.0.0.1, lo0, rej
C>* 10.0.237.110/32 is directly connected, ath0
C>* 10.177.20.0/24 is directly connected, sip0
K * 127.0.0.0/8 via 127.0.0.1 inactive, rej
C>* 127.0.0.0/8 is directly connected, lo0
C>* 169.254.0.0/16 is directly connected, ath0
S>* 224.0.0.5/32 [1/0] via 127.0.0.1, lo0
S>* 224.0.0.6/32 [1/0] via 127.0.0.1, lo0
S>* 224.0.0.9/32 [1/0] via 127.0.0.1, lo0

Regards;
Lawrence

On 3/7/07, David Young <dyoung at pobox.com> wrote:
>
> On Wed, Mar 07, 2007 at 05:11:21PM +0200, Socrates Socrates wrote:
> > Hi David;
> >
> > With regard to HSLS linux port not receiving packets from CUWiN box,
> I've
> > gotten libevent-1.0c and libevent-0.8a .
> > I tested these versions with the old code and they work just fine. I
> also
> > tried these versions on the latest code with no change in the behaviour
> of
> > the latest code.
> > So I am pretty much certain that libevent is not the issue.
> >
> > I noticed, for example, that the *struct hsls_interface* passed to
> > EVTIMER_SET in function hsls_interface_create is much lager in the new
> code
> > than on the older code.
> > Is there anything in the 3rd argument of EVTIMER_SET (and/or related
> macros)
> > that could possibly affect events not being detected?
> >
> > I believe that the arguments/structures past to EVTIMER_SET (and/or
> related
> > macros)  are most likely the cause of the problem.
> > Trouble is the structures are so big to know exactly which member of the
> > structure to check out.
> >
> > What is the event that should be detected (or occur) after some timeout
> (if
> > any)?
>
> EVTIMER_SET is a wrapper for evtimer_set, the libevent subroutine.
> The libevent documentation explains how evtimer_set works.  When the
> interval set by EVTIMER_ADD in hsls_interface_hello_sched() has passed,
> libevent will call the subroutine you provide to EVTIMER_SET with the
> argument you provide, that is, it will call hsls_interface_hello_cb((void
> *)hi).  Make sure that both EVTIMER_SET and EVTIMER_ADD are called.
> See if hsls_interface_hello_cb is ever called.
>
> > Oh, while running the new code, I do *netstat -nl* and I noticed the
> Recv-Q
> > counter associated with address:Port (0.0.0.0:9191) incrementing,
> showing
> > that the packets from CUWiN box do arrive but do not get collected.
>
> It sounds to me like there is a general problem with event dispatch.
>
> Dave
>
> --
> David Young             OJC Technologies
> dyoung at ojctech.com      Urbana, IL * (217) 278-3933
> _______________________________________________
> CU-Wireless-Dev mailing list
> CU-Wireless-Dev at lists.cuwireless.net
> http://lists.chambana.net/cgi-bin/listinfo/cu-wireless-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.chambana.net/mailman/archive/cu-wireless-dev/attachments/20070309/4dcaa064/attachment.htm