| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8 9 10 11
Comments:
<0> On other file, it warned when it didn;t like permissions
<0> On other file, it didn't even warn
<0> Subtle
<1> which one did you remove the extra permissions from?
<0> authorized_keys and known_hosts
<2> perhaps it can't warn for security reasons.
<1> that's funny. mine is :
<1> -rw-r--r-- 1 jeffloc jeffloc 233 2006-05-19 12:51 authorized_keys
<1> -rw------- 1 jeffloc jeffloc 951 2006-05-19 12:47 id_rsa
<1> -rw-r--r-- 1 jeffloc jeffloc 233 2006-05-19 12:47 id_rsa.pub
<1> -rw-r--r-- 1 jeffloc jeffloc 442 2006-07-12 16:08 known_hosts
<2> it would be advertising that the user was insecure.
<3> Extra permissions caused problems? Unexpected...
<1> doesn't seem to bother it
<0> ssh --version ?
<0> ah , mine was worse
<0> -rw-rw-r-- 1 lerner root 394 Jul 12 08:04 authorized_keys
<0> rw
<1> mine doesn't like ssh --version
<2> most servers are like that. they want fairly exact permissions, because weirdnesses have been known to cause problems.
<1> it uses -V OpenSSH_4.3p2 Debian-2, OpenSSL 0.9.8b 04 May 2006
<1> I think it woouldn't have liked the w in group and other
<0> right
<0> pedantic daug
<1> well it is a security thing
<4> OpenSSH_3.8.1p1, OpenSSL 0.9.7i 14 Oct 2005
<5> is there any reason why my code which uses select() works on win32 but not freebsd?
<3> What do you get on BSD?
<5> like on win32 i connect and it works but on freebsd i connect but its like it does nothing after accept()
<3> calc paste
<6> Please paste your code (or a complete example that demonstrates your problem) here: http://rafb.net/paste/
<5> ...
<7> kthx^, how complicated is your select code? Does the accept() return?
<5> well on win32 it works perfect
<3> If you won't share the code, that might take a long while
<5> after i accept
<5> lol let me upload it then
<5> btw it has no comments
<5> http://rafb.net/paste/results/L7PDeZ40.html
<3> iSelectSize is not computed anywhere, your socket is not being watched by select()
<5> iSelectSize is a global
<3> iSelectSize = 0;
<5> i allready declare it
<3> Line 12
<0> iSelectSize is probably unused on wni32
<0> it's needed on unix, though
<3> It contains 0! This is wrong
<5> why
<3> man select
<5> its declared as 0 and added 1 to it every new client
<5> and select uses it + 1
<5> why is this wrong
<3> And that is wrong, the value must be the highest fd +1
<5> int iResult = select(iSelectSize+1,&iReadfds,0,0,&iTime);
<5> it has +1
<5> oh wait
<3> The _highest_ file descriptor being p***ed to select() plus one
<5> shouldnt i declare it as iSelectSize - 1; coz of the listining socket?
<5> ;o
<0> it's max fd + 1
<5> oh i get it
<5> -_-
<5> wewt works
<3> :) Good
<5> is it placebo to use SO_RECVTIMEO with select() using a timeout() ?
<5> nvm
<3> Hum, I don't recall ever seeing such a socket option...
<5> when it fails its sumthin like WouldBlock()....
<5> i dunno
<5> -__
<5> -_-*
<3> You may want to switch to non-blocking sockets and select() then
<5> i am
<5> does SO_SNDTIMEO work on non blocking sockets?
<8> I'm using recvfrom/sendto to have a 'conversation' in udp, but I can't seem to get sendto() to use the outbound IP that recvfrom() recieved *on* (I'm binding on multiple IPs). How would I do that?
<8> I bind on all interfaces, I recieve a packet on 192.168.0.10, and I send one in reply from 192.168.0.12 - stuff breaks.
<3> I don't think that option even exists, kthx^, not on Unix
<5> it does i looked on linux.about
<3> Guessing from the name, a send timeout and non-blocking don't seem very well compatible
<5> ok
<1> daxxar, are you sure recvfrom reading the address and port number properly
<1> post your source code
<1> calc paste
<6> Please paste your code (or a complete example that demonstrates your problem) here: http://rafb.net/paste/
<1> paste rather
<8> jeffloc, I mean the IP address the UDP packet was sent to, not from.
<1> so it recieves it but breaks istead of replying. or do I have it all wrong?
<8> jeffloc, it recieves, and replies nicely, but the source address of the reply needs to be the same as the destination address of the inbound message. (if you understand)
<8> I think I found what I needed: IP_PKTINFO on Linux
<1> you should be able to do it straight out
<8> No, recvfrom() does not (without IP_PKTINFO) give any info about the destination address, only the source.
<8> I need recvmsg and IP_PKTINFO, afaik.
<8> But thanks. :)
<1> no you don't
<1> recvfrom can be used the way you wanted to
<1> you must have done it a little wrong
<1> easy enough to do
<1> I did have a little example program for that but I can't find it
<1> or I'd send it to you
<1> if you are still around after I have my dinner. I'll write a quick example for you
<1> about 30 minutes
<5> on select() a client sends some data fastly then only parts of it get sent because it has to process the first message and by the time it finishes the client has sent the third message thereby missing the second message
<5> any ways around this?
<1> you could have the client wait for a reply
<5> ?
<5> like say if the client sent 1 then 2 then 3 then 4
<5> i wouldnt recv 3
<5> for eg
<3> Then have the receiving end knows what to expect
<5> i dont get it ;/
<3> Example : each message got a header where the length of the message is actually stored, and the client doesn't do anything until it received at least that heaer
<5> how would that fix it
<5> i thought it is select()
<5> it misses the recv signal coz its processin and older one
<3> That doesn't seem to make much sense
<5> well because
<3> Always buffer what you are receiving, so you can make sense of it when messages are complete
<5> but how can select recv a msg if its in the middle of processing (single threaded)
<3> The kernel receives the data and buffers up to a certain point, select() is used to check what file descriptors have got anything for you to read
<1> he's talking about select. he runs select , it detects the first message , then while his server is still processing the first one, the client could have sent 2 or more. so next time he executes select it returns and he reads one message
<1> so his server doesn't know there are more than one waiting
<3> Sockets receive data even outside of select(), obviously
<5> yes thats correct jeffloc
<1> nonblocking read
<3> Read all the messages you have buffered and complete before the next time you execute select(), I still don't get what the problem seems to be
<1> when select says something is there , read it, then do another read , and another until it returns that there is nothing to read. then do select again
<3> buffered and completed*
<3> Right.
<5> jeffloc
<5> so your saying do recv
<5> then do another loop with fd_isset with recv again?
<1> with the nonblocking flag
<5> what is this?
<5> i set it to nonblocking
<1> no keep doing recv until it returns empty
<1> look at the man file
<5> ugh k
<5> good idea thx
<1> MSG_DONTWAIT flag
<5> whats that?
<5> if you set it to nonblocking mode is that needed?
<1> no not if you set it but why bother doing that
<1> computers are lazy. they like doing things the simplest way
<5> is that flag win compatible?/
<1> or is that programmers
<1> probably. you'll have to look in the docs
<1> for recv
<5> k
<1> they are both based on berkley unix 4.3
<5> would it be better to do multi threadeing and create a thread for msg processing?
Return to
#c
or
Go to some related
logs:
footsiebabes share
#sendmail
#computers
#microsoft
#stocks
#heroin
regulation of cohabitation and marriage in canada
crip walk animation -video
wedding in indeia
#linux-noob
|
|