--0-1262115880-1044351756=:69718
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit


Yes I will have a look.  It's probably going to take a few days, but I'll get there in the end.
Thanks, Philip
 Jaromir Dolecek <jdolecek@netbsd.org> wrote:After a very brief look, it seems the call graph is like this:

sys_sendto() -> (massages args)
sendit() -> further massaging into mbufs
so->so_send -> 
sosend() -> actually send the data to protocol layer in chunks
so->so_proto->pr_usrreq(PRU_SEND) ->
clnp_usrreq(PRU_SEND) -> no special handling for PRU_SEND, passes down
raw_usrreq(PRU_SEND) -> calls clnp_usrreq(PRU_CONNECT) if nam
is nonnull (it.e. if address was specified for sendto(2) call), then 
invokes protocol output function, I assume rclnp_output()

Now, clnp_usrreq(PRU_CONNECT) does fill in isop_sfaddr and rcb_faddr,
it seems everything is correct there. So it should work.

Since it doesn't work for you, can you confirm clnp_usrreq(PRU_CONNECT)
is really called during your sendto(2) call, and that the address is
correctly filled in? If it's not called, there must be something
I overlook. If it is called, then something else must erase the address
between PRU_CONNECT and rest of raw_usrreq() handling. Perhaps confirm
that the condition in clnp_usrreq(PRU_CONNECT) for m_len and siso_len
doesn't fire, and that it actually validates and sets the internal
socket address properly. 

Jaromir 


Philip Christian wrote:
[ Charset ISO-8859-1 unsupported, converting... ]
> 
> I have spent now about six weeks trying to get a SOCK_RAW send() or sendto() call to work with an ISO socket and came to the conclusion that it is broken.
> 
> Basically I have figured out that the send() or sendto() calls results in rclnp_output function in clnp_raw.c being called which calls function clnp_output in clnp_output.c
> 
> send() or sendto() seem to fail because 
> rp->risop_isop.isop_faddr->siso_addr.isoa_len
> and
> rp->risop_isop.isop_faddr->siso_addr.isoa_genaddr[]
> do not get populated properly with the destination address before function rclnp_output is executed.
> 
> In fact I have manually forced an address into this structure inside the rclnp_output function and recompiled the kernel, and a packet is then actually transmitted.
> 
> I cannot figure out what the kernel does when send() or sendto() are executed.
> There are various tables of system calls in places like /sys/syscall.h but I can't get from there to the actual code.
> 
> I have also had a look at the Design and Implementation of the 4.4 BSD Operating System book and I still couldn't figure it out.
> 
> Can someone point me in the right direction so that I can figure out why the address is not getting from the connect() or sendto() dest address arguments into rp->risop_isop.isop_faddr please ?
> 
> Really I just want a pointer to the code that gets executed, so it almost isn't even an OSI specific question...
> 
> Thanks, Philip
> 
> 
> 
> 
> 
> ---------------------------------
> With Yahoo! Mail you can get a bigger mailbox -- choose a size that fits your needs


-- 
Jaromir Dolecek http://www.NetBSD.org/
-=- We should be mindful of the potential goal, but as the tantric -=-
-=- Buddhist masters say, ``You may notice during meditation that you -=-
-=- sometimes levitate or glow. Do not let this distract you.'' -=-



---------------------------------
With Yahoo! Mail you can get a bigger mailbox -- choose a size that fits your needs

--0-1262115880-1044351756=:69718
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<P>Yes I will have a look.&nbsp; It's probably going to take a few days, but I'll get there in the end.
<P>Thanks, Philip
<P>&nbsp;<B><I>Jaromir Dolecek &lt;jdolecek@netbsd.org&gt;</I></B> wrote:
<BLOCKQUOTE style="BORDER-LEFT: #1010ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">After a very brief look, it seems the call graph is like this:<BR><BR>sys_sendto() -&gt; (massages args)<BR>sendit() -&gt; further massaging into mbufs<BR>so-&gt;so_send -&gt; <BR>sosend() -&gt; actually send the data to protocol layer in chunks<BR>so-&gt;so_proto-&gt;pr_usrreq(PRU_SEND) -&gt;<BR>clnp_usrreq(PRU_SEND) -&gt; no special handling for PRU_SEND, passes down<BR>raw_usrreq(PRU_SEND) -&gt; calls clnp_usrreq(PRU_CONNECT) if nam<BR>is nonnull (it.e. if address was specified for sendto(2) call), then <BR>invokes protocol output function, I assume rclnp_output()<BR><BR>Now, clnp_usrreq(PRU_CONNECT) does fill in isop_sfaddr and rcb_faddr,<BR>it seems everything is correct there. So it should work.<BR><BR>Since it doesn't work for you, can you confirm clnp_usrreq(PRU_CONNECT)<BR>is really called during your sendto(2) call, and that the address is<BR>correctly filled in? If it's not call
 ed, there must be something<BR>I overlook. If it is called, then something else must erase the address<BR>between PRU_CONNECT and rest of raw_usrreq() handling. Perhaps confirm<BR>that the condition in clnp_usrreq(PRU_CONNECT) for m_len and siso_len<BR>doesn't fire, and that it actually validates and sets the internal<BR>socket address properly. <BR><BR>Jaromir <BR><BR><BR>Philip Christian wrote:<BR>[ Charset ISO-8859-1 unsupported, converting... ]<BR>&gt; <BR>&gt; I have spent now about six weeks trying to get a SOCK_RAW send() or sendto() call to work with an ISO socket and came to the conclusion that it is broken.<BR>&gt; <BR>&gt; Basically I have figured out that the send() or sendto() calls results in rclnp_output function in clnp_raw.c being called which calls function clnp_output in clnp_output.c<BR>&gt; <BR>&gt; send() or sendto() seem to fail because <BR>&gt; rp-&gt;risop_isop.isop_faddr-&gt;siso_addr.isoa_len<BR>&gt; and<BR>&gt; rp-&gt;risop_isop.isop_faddr-&gt;sis
 o_addr.isoa_genaddr[]<BR>&gt; do not get populated properly with the destination address before function rclnp_output is executed.<BR>&gt; <BR>&gt; In fact I have manually forced an address into this structure inside the rclnp_output function and recompiled the kernel, and a packet is then actually transmitted.<BR>&gt; <BR>&gt; I cannot figure out what the kernel does when send() or sendto() are executed.<BR>&gt; There are various tables of system calls in places like /sys/syscall.h but I can't get from there to the actual code.<BR>&gt; <BR>&gt; I have also had a look at the Design and Implementation of the 4.4 BSD Operating System book and I still couldn't figure it out.<BR>&gt; <BR>&gt; Can someone point me in the right direction so that I can figure out why the address is not getting from the connect() or sendto() dest address arguments into rp-&gt;risop_isop.isop_faddr please ?<BR>&gt; <BR>&gt; Really I just want a pointer to the code that gets executed, so it almost isn
 't even an OSI specific question...<BR>&gt; <BR>&gt; Thanks, Philip<BR>&gt; <BR>&gt; <BR>&gt; <BR>&gt; <BR>&gt; <BR>&gt; ---------------------------------<BR>&gt; With Yahoo! Mail you can get a bigger mailbox -- choose a size that fits your needs<BR><BR><BR>-- <BR>Jaromir Dolecek <JDOLECEK@NETBSD.ORG>http://www.NetBSD.org/<BR>-=- We should be mindful of the potential goal, but as the tantric -=-<BR>-=- Buddhist masters say, ``You may notice during meditation that you -=-<BR>-=- sometimes levitate or glow. Do not let this distract you.'' -=-</BLOCKQUOTE><p><p><br><hr size=1><a href="http://uk.yahoo.com/mail/tagline_xtra/?http://uk.docs.yahoo.com/mail_storage.html"><b><font face="Arial" size="2">With Yahoo! Mail you can get a bigger mailbox -- choose a size that fits your needs</font></b></a><br>
--0-1262115880-1044351756=:69718--