[Xastir] Xastir 1.3.xx and wx200d problems

[Stefano Angelo Mario Lassini]

I agree with the analysis you make of this. I will have to wait until I
get back home tonight to try ethereal and see what it tells me. I haven't
used that tool in the past, but hopefully it is available in the Suse 9.0
pro distro, in which case it will only take a minute to install it on my
machine.

I'll check and report what I find.

Thanks,

--sam
> Sam,
>
> 	What I'm thinking is that one side or the other isn't fully closing.  I
> was hoping that a trace from Ethereal would give some indication as to
> where the TCP-CLOSE (FIN?) wasn't being completed.
>
> 			THX/BDH
>
>
>
> On Wed, 2004-04-28 at 10:14, Stefano Angelo Mario Lassini wrote:
>> Brian,
>>
>> Thanks for the suggestion.
>> I am able to ascertain that many sockets on the wx200d side are left in
>> a
>> CLOSE_WAIT state that causes them to hang forever (until the wx200d
>> process is killed and restarted). This happens both with sockets opened
>> from xastir and with sockets opened from the wx200 command line client
>> for
>> wx200d, so it seems to be a problem that goes beyond xastir.
>>
>> BTW, the connections are local, i.e. both xastir and the wx200d daemon
>> are
>> running on the same machine (I might migrate wx200d to another machine
>> once I get this issue figured out).
>>
>> --sam
>> > Sam,
>> >
>> > 	Do you have Ethereal on either of the Linux machines in question?  I
>> > think you've got something not fully closing a socket.  If you can get
>> a
>> > trace of it you should be able to see what is being left hanging.
>> >
>> > 			THX/BDH
>> >
>> >
>> > On Mon, 2004-04-26 at 21:10, Stefano Angelo Mario Lassini wrote:
>> >> Over the past few weeks I have experienced failures in my
>> xastir/wx200d
>> >> setup
>> >> that would cause wx200d to stop responding after a couple of days or
>> >> less of
>> >> uptime. If xastir was not connected to the network wx port wx200d
>> would
>> >> run
>> >> for many days at a time without problems.
>> >>
>> >> I eventually traced the symptoms to the fact that the number of open
>> >> sockets
>> >> to wx200d would increase to the point that several hundreds of socket
>> at
>> >> a
>> >> time were open to wx200d (or so appears by listing /proc/{wx200d
>> >> PID}/fd.
>> >> Apparently every time that Xastir believes that the connectoin to
>> wx200d
>> >> is
>> >> down (due to lack of wx200d activity) it attempts to re-connect and
>> in
>> >> the
>> >> process a new socket is created and the old one is left hanging.
>> >>
>> >> Once the number of sockets grows beyond the number of file
>> descriptors
>> >> available to wx200d the daemon hangs, and needs to be killed and
>> >> restarted.
>> >>
>> >> I have tried to look at the code responsible for the networked
>> weather
>> >> station, but I have to admit that my understanding of the structure
>> of
>> >> the
>> >> xastir code base is pretty weak...
>> >>
>> >> Can anyone provide me any insight on what is going on, and where to
>> look
>> >> to
>> >> possibly attempt to trace and fix this behaviour?
>> >>
>> >> I have an Oregon scientific WMR-968 wirelessweather station that I do
>> nt
>> >> seem
>> >> to be able to connect to xastir directly (I tried several
>> combinations
>> >> of
>> >> baud rates with no sucess), so wx200d is my only alternative at the
>> >> moment,
>> >> and I would also like to be able to use the wx200d daemon to upload
>> wx
>> >> data
>> >> to other applications in the future.
>> >>
>> >> The above behaviour happens in 1.3.1, 1.3.2 and in a CVS update from
>> >> last
>> >> week.
>> >>
>> >> Thanks for the help,
>> >>
>> >> Sam
>> >> N8USY
>> > --
>> > ------------------------------------------------------------------
>> > Brian D Heaton
>> > Senior Network Engineer
>> > Janus Research Group
>> > (706) 791-8342
>> > GPG Fingerprint: C99E 3E9C E23A 4E47 46F4 0A77 3A45 CB65 9E19 5B0A
>> >
> --
> ------------------------------------------------------------------
> Brian D Heaton
> Senior Network Engineer
> Janus Research Group
> (706) 791-8342
> GPG Fingerprint: C99E 3E9C E23A 4E47 46F4 0A77 3A45 CB65 9E19 5B0A
>


-- 
Stefano 'SAM' Lassini
stefano at ieee.org