Subject: Re: how is dest addr handled by connect() or sendto() code ?
To: Philip Christian <email@example.com>
From: Jaromir Dolecek <firstname.lastname@example.org>
Date: 02/08/2003 12:15:18
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.
> 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 <email@example.com> 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.
> 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 <jdolecek@NetBSD.org> 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.'' -=-