when I use linux's "sendto(....)" to send some udp packet, I got "invalid argument" error from system.
After some check, I found that I try to send a udp packet via a v6 socekt to a ipv4 destination
, I'm not sure whether it is the reason why "invalid argument" comes from system, so want to raise my question here.
Yes, a PF_INET6 socket can send to IPv4 destination addresses with sendto() - as long as you haven't bound it to an IPv6 local address, anyway.
Related
On my system I have multiple IP addressed. A UDP socket is listening to them all by binding to 0.0.0.0:5005.
Call recvfrom to wait for data.
In the response a sockaddr is filled with the address of the remote sender.
But how do I get to know which of my local IP the packet was sent to?
Is the a way to know?
Or do I need to explicitly open a socket for each IP address on the system?
Currently i have facing one problem in portrestrictedcone nattype.When my udp client hit the server with test1.dns.com (to sepcific IP 111.111.111.111 and this ip is bind with DNS test1.dns.com) where i am getting response from different IP and not with 111.111.111.111, however the same scenario is working for fullcone nattype. If the server response from the same above ip i am able to get the response.
Currently there are two services running on the server on UDP, one is which is working in portrestrictedcone and send response on same IP as a result i am getting the response, however second service is not behaving in same was as first service works.
i am running both the services on same DNS as i have describe above.
Can i get the help what i need to change on the server or client side to get this resolve?
I think your problem is that you are not sending the packet to the port you received it from (Allocated by NAT). When you receive a packet, check the port that was used to send it then send your response to that port and not to a predefined port because the NAT might change it.
I have an application that uses sendto() with UDP to check resources on different ports. How can I get the ICMP port unreachable packet using recvfrom()?
My recvfrom() is like this:
SOCKADDR_STORAGE saFrom;
int nFromLen = sizeof( SOCKADDR_STORAGE );
nReceived = recvfrom ( Socket, Buffer, BufferSize, 0, ( struct sockaddr * ) &saFrom, (socklen_t *)&nFromLen );
When an ICMP port unreachable occurs, nReceived = -1, and WSAGetLastError() returns WSAECONNRESET(10054).
But since I'm checking on different ports, I'd like a way of determining which port triggered the ICMP port unreachable message. How can I determine that? (Maybe I can set some socket options?)
Edit:
As per Len's suggestion(use ICMP only), I tried to create a socket by socket (AF_INET, SOCK_RAW, IPPROTO_ICMP), then call recvfrom() on it. recvfrom() returns 10022(WSAEINVAL) error because the socket is not bound. How should I fix that?
You can't, see my blog posting on the subject here: http://www.lenholgate.com/blog/2007/12/bug-in-overlapped-udp-port-unreachable-errors.html
If you're on XP, then you can use SIO_UDP_CONNRESET with WSAIoctl to control if you get ERROR_PORT_UNREACHABLE reported rather than WSAECONNRESET but even with that set (or on an OS where this is the default) you still do not get the address of the remote port where the ICMP port unreachable happened.
I suggest you use one socket per port you're checking, that way you'll be able to determine where the error came from. Or use ICMP directly.
I have a system that is running on windows.
I have in that system a process that waits for another process on the same machine for a udp message. The message itself is not important (garbage), but the important thing is that I got the event of the message itself.
The problem is that it seems that I get from another local program a UDP message and I don't know from where. I added information about the sender in the recieved UDP message. I see that I get message from valid local port but also from the addres 0.0.0.0 .
I can't understand the 0.0.0.0 . Does anyone has an idea ?
A computer without an assigned IP address could send such packet, even across the network - see e.g. a similar mechanism in DHCP, where the DHCP discovery packet is sent with source address of 0.0.0.0
On a local computer, could this be that the packet is sent (and received) on an interface that is up but without an IP address?
Also, this can mean "broadcast" - if this article on e2 is correct, it is a deprecated method of making a broadcast packet, but apparently it was never removed.
Because it is a udp message and using async type, when reading messages that arrive from the other program I can't know when stop reading, when I get reading the message and I get 0.0.0.0 it means I read everything from the UDP buffer from OS.
I'm on a local LAN with only 8 connected computers using a netgear 24 port gigabit switch, network load is really low and send/receive buffers on all involved nodes(running slackware 11) have been set to 16mb. I'm also running tcpdump on each node to monitor the traffic.
A sending node sends a 10044byte large UDP packet which more often than not (3/4 times) does not end up in the receiving side application, in these cases I notice(using tcpdump) that the first x fragments are missing and only the last 3 (all with offsets > 0 and in order) are caught by tcpdump. The fragmented UDP package can therefore not be reassembled and is most likely thrown away.
I find the missing fragments strange since I have also tried a simple load test bursting out 10000 UDP messages of the same size, the receiving application sends a response and all tests so far gives 100% responses back.
Any clues or hints?
Update!
After resuming the testing of the above mentioned software I found a repeatable way of recreating the error.
Using windump on the sending windows machine, and tcpdump on the receiving machine, after having left the application idle for some time(~5 minutes), I tried sending the udp message but only end up with a single fragment caught by windump and tcpdump, the 3 remaining fragments are lost. Sending the same message one more time works fine and booth windump and tcpdump catches all 4 fragments and the application on the receiving side gets the message. The pattern is repeatable.
Started searching and found the following information, but to me, still not a clear answer.
http://www.eggheadcafe.com/software/aspnet/32856705/first-udp-message-to-a-sp.aspx
Re examining the logs I now notice the ARP request/reply being sent, which matches one of the ideas given in the link above.
NOTE! I filter windump on the sending side using: "dst host receivernode"
Capture from windump: first failed udp message, should be 4 fragments long
14:52:45.342266 arp who-has receivernode tell sendernode
14:52:45.342599 IP sendernode> receivernode : udp
Capture from windump: second udp message, exactly the same contents, all 4 fragments caught
14:52:54.132383 IP sendernode.10104 > receivernode .10113: UDP, length 6019
14:52:54.132397 IP sendernode> receivernode : udp
14:52:54.132406 IP sendernode> receivernode : udp
14:52:54.132414 IP sendernode> receivernode : udp
14:52:54.132422 IP sendernode> receivernode : udp
14:52:56.142421 arp reply sendernode is-at 00:11:11:XX:XX:fd (oui unknown)
Anyone who has a good idea about whats happening? please elaborate!