|
From: Steven W. <st...@gw...> - 2003-09-30 21:07:28
|
Hi, >=20 > 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. >=20 > In fact, since the last email, we have found that the ADA program rejec= ted our=20 > connexion because of some data wanted from the optdata_dn->opt_data str= ucture=20 > and that the failure was from the software and not from the network lay= er.=20 > So, you were right. >=20 > DNSTAT_REJECTED seems really generated by the software layer. >=20 > 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 ? >=20 > We used setsockopt() witch DSO_CONDATA : Get/set connect data (struct=20 > optdata_dn) > Thats the usual way to do it. There is no equivalent in TCP/IP as you say. The reason for it is so that your application can pass a few bytes of data in a connect init message. You can "half accept" a socket in DECnet where the listening end sends no response until after the accept() call has returned. This allows the application to send an accept/reject based on the contents of the connect init message and thus its useful for the connecting application to be able to send some extra info. > > It depends on what the other end expects to see. Mostly it appears th= at > > it is not optional from the DEC applications I've seen interacting > > with Linux DECnet. >=20 > For the moment, we need to use accounting information. It should depend= of=20 > applications. > Yes, it will. =20 > > Well ADA has bindings to the POSIX network API afaik, so if you are u= sing > > those, all the features of Linux DECnet should be available. As for A= DA > > on VAXen, I have no experience at all. >=20 > It's a very good information and from now, it seems to be correct. In f= act,=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 ! > Well its not perfect, but we try :-) =20 > > Ok. If you have a way to set up a correctly working connection (witho= ut > > 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 forma= ts > > (bar one!) are listed in the DECnet documents. The one missing bit re= lates > > 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 s= end > > which type. >=20 > It's the next step. Try to understand a little more all the packet laye= r. We=20 > have found a tool (unfortunatly under Windows, and not gpl) which is ab= le to=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. >=20 > Thanks for your comments and your support, > Lionel >=20 Ok. Beware that some (all?) versions of tcpdump don't dump DECnet correctly. You might find it easier to dump it out as raw data and deocde it yourself using the specs - thats what I tend to do, Steve. |
