|
From: Lionel T. <lio...@fr...> - 2003-09-30 20:55:50
|
Le Lundi 29 Septembre 2003 18:24, Steven Whitehouse a =E9crit : > > If you talk about the sockaddr_dn structure, i think it's correctly > > configured (it's a named object) : > > > > sockaddr.sdn_family =3D AF_DECnet; > > sockaddr.sdn_flags =3D 0x00; > > sockaddr.sdn_objnum =3D 0x00; /* for a named object ? */ > > sockaddr.sdn_objname =3D "TASK"; > > sockaddr.sdn_objnamel =3D 4; > > memcpy(sockaddr.sdn_add.a_addr, np->n_addr,2); > > ... > > That looks ok, and you are right that objnum =3D 0 for named objects. In fact, since the last email, we have found that the ADA program rejected = our=20 connexion because of some data wanted from the optdata_dn->opt_data structu= re=20 and that the failure was from the software and not from the network layer.= =20 So, you were right. DNSTAT_REJECTED seems really generated by the software layer. But ! I have a question about the origin of that kind of structure=20 (optdata_dn->opt_data, max size of 16 bytes) ? It's seems to be very=20 different from ip network where you don't have such optional structure of=20 data (i think). How is it used usually ? We used setsockopt() witch DSO_CONDATA : Get/set connect data (struct=20 optdata_dn) > It depends on what the other end expects to see. Mostly it appears that > it is not optional from the DEC applications I've seen interacting > with Linux DECnet. =46or the moment, we need to use accounting information. It should depend o= f=20 applications. > Well ADA has bindings to the POSIX network API afaik, so if you are using > those, all the features of Linux DECnet should be available. As for ADA > on VAXen, I have no experience at all. It's a very good information and from now, it seems to be correct. In fact,= =20 Linux seems perfect to recycle old VAX program, even written in ADA :-) You= ,=20 and other Decnet developpers, have done a really good job ! > Ok. If you have a way to set up a correctly working connection (without > Linux DECnet) you should be able to use tcpdump or some similar tool to > work out whats going on and reverse engineer it. All the packet formats > (bar one!) are listed in the DECnet documents. The one missing bit relates > to the formatting of the "end user names" where the formats are shown, but > the uses are not explained that well - the Linux code knows when to send > which type. It's the next step. Try to understand a little more all the packet layer. W= e=20 have found a tool (unfortunatly under Windows, and not gpl) which is able t= o=20 dump decnet packet into xml files : guess that it would be much easier to=20 understand packets. Of course, tcpdump is a good candidate. Thanks for your comments and your support, Lionel |
