Subject: Re: how is dest addr handled by connect() or sendto() code ?
To: Jaromir Dolecek <jdolecek@netbsd.org>
From: =?iso-8859-1?q?Philip=20Christian?= <philipchristian2003@yahoo.co.uk>
List: tech-kern
Date: 02/10/2003 16:11:57
--0-1342911174-1044893517=:68386
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Yes your method works, I removed the if statement and the bcopy that I had added and it works fine.
I can't get recv() to work on a SOCK_RAW clnp socket though.........
Program seems to just sit there waiting for a packet that never comes (even though I do send one). Currently I'm looking suspiciously at raw_input in net/raw_usrreq.c
Philip
Jaromir Dolecek <jdolecek@netbsd.org> wrote:Philip Christian wrote:
> Success! I can SOCK_RAW sendto() clnp packets now.
> If you go to /sys/netiso/clnp_raw.c
> and after line 376 add a new line 377 (old 377 becomes 378 etc)
> bcopy(sisotosa(addr),rp->risop_rcb.rcb_faddr, sizeof(*addr));
> and re-compile then it works.
I noticed the place which is being problematic I think.
There is the condition
if (addr->siso_family != AF_ISO)
rp->risop_isop.isop_sfaddr = *addr;
just before faddr pointer setup. I think the if () is not correct,
and probably pasto from other != AF_ISO checks.
Can you check if stuff works if you remove the condition, and
leave just the:
rp->risop_isop.isop_sfaddr = *addr;
(and take out the newly added bcopy()).
If you confirm it works, I'll commit the change to master NetBSD tree.
Jaromir
> I have sample code to test it if anyone want to send a CLNP packet.
> I believe that this is the right way to do it as the rclnp_output() function does look in rp->risop_rcb.rcb_faddr for a destination address, and, documentation that I have says that that is where a raw socket is supposed to put the dest address. Line 376 initialises the pointer, but then they just forgot to actually put the address in.
> Thanks for you help Jaromir, I would not have found it without your help.
> Regards Philip
> Jaromir Dolecek 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
--
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-1342911174-1044893517=:68386
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
<P>Yes your method works, I removed the if statement and the bcopy that I had added and it works fine.
<P>I can't get recv() to work on a SOCK_RAW clnp socket though.........
<P>Program seems to just sit there waiting for a packet that never comes (even though I do send one). Currently I'm looking suspiciously at raw_input in net/raw_usrreq.c
<P>Philip
<P> <B><I>Jaromir Dolecek <jdolecek@netbsd.org></I></B> wrote:
<BLOCKQUOTE style="BORDER-LEFT: #1010ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">Philip Christian wrote:<BR>> Success! I can SOCK_RAW sendto() clnp packets now.<BR>> If you go to /sys/netiso/clnp_raw.c<BR>> and after line 376 add a new line 377 (old 377 becomes 378 etc)<BR>> bcopy(sisotosa(addr),rp->risop_rcb.rcb_faddr, sizeof(*addr));<BR>> and re-compile then it works.<BR><BR>I noticed the place which is being problematic I think.<BR>There is the condition<BR><BR>if (addr->siso_family != AF_ISO)<BR>rp->risop_isop.isop_sfaddr = *addr;<BR><BR>just before faddr pointer setup. I think the if () is not correct,<BR>and probably pasto from other != AF_ISO checks.<BR>Can you check if stuff works if you remove the condition, and<BR>leave just the:<BR><BR>rp->risop_isop.isop_sfaddr = *addr;<BR><BR>(and take out the newly added bcopy()).<BR><BR>If you confirm it works, I'll commit the change to master NetBSD tree.<BR><BR>Jaromir<BR><BR>> I have samp
le code to test it if anyone want to send a CLNP packet.<BR>> I believe that this is the right way to do it as the rclnp_output() function does look in rp->risop_rcb.rcb_faddr for a destination address, and, documentation that I have says that that is where a raw socket is supposed to put the dest address. Line 376 initialises the pointer, but then they just forgot to actually put the address in.<BR>> Thanks for you help Jaromir, I would not have found it without your help.<BR>> Regards Philip<BR>> Jaromir Dolecek <JDOLECEK@NETBSD.ORG>wrote:After a very brief look, it seems the call graph is like this:<BR>> <BR>> sys_sendto() -> (massages args)<BR>> sendit() -> further massaging into mbufs<BR>> so->so_send -> <BR>> sosend() -> actually send the data to protocol layer in chunks<BR>> so->so_proto->pr_usrreq(PRU_SEND) -><BR>> clnp_usrreq(PRU_SEND) -> no special handling for PRU_SEND, passes down<BR>> raw_usrreq(P
RU_SEND) -> 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 called, 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>> Phi
lip Christian wrote:<BR>> [ Charset ISO-8859-1 unsupported, converting... ]<BR>> > <BR>> > 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>> > <BR>> > 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>> > <BR>> > send() or sendto() seem to fail because <BR>> > rp->risop_isop.isop_faddr->siso_addr.isoa_len<BR>> > and<BR>> > rp->risop_isop.isop_faddr->siso_addr.isoa_genaddr[]<BR>> > do not get populated properly with the destination address before function rclnp_output is executed.<BR>> > <BR>> > 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.<B
R>> > <BR>> > I cannot figure out what the kernel does when send() or sendto() are executed.<BR>> > 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>> > <BR>> > 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>> > <BR>> > 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 ?<BR>> > <BR>> > Really I just want a pointer to the code that gets executed, so it almost isn't even an OSI specific question...<BR>> > <BR>> > Thanks, Philip<BR>> > <BR>> > <BR>> > <BR>> > <BR>> > <BR>> > ---------------------------------<BR>> > With Yahoo! Mail you can get a bigger mailbox -- choose a siz
e that fits your needs<BR>> <BR>> <BR>> -- <BR>> Jaromir Dolecek 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.'' -=-<BR>> <BR>> <BR>> <BR>> ---------------------------------<BR>> 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 bigg
er mailbox -- choose a size that fits your needs</font></b></a><br>
--0-1342911174-1044893517=:68386--