Forums Bug Reports udp socket - random port

When opening two udp sockets in the same scope, mirc select the same local port if we don't use one :
Type
then


can't reproduce the behavior with :

tested on mIRC 7.16

mIRC is not actually re-using the same local port. The problem is that $sock().sport returns "the source ... port of the last received UDP packet". The event "ON UDPREAD" doesn't get an opportunity to execute until after both /sockudp commands have been issued. By the time the event does execute (in response to the first UDP packet), the last received UDP packet is already the second one. Unfortunately, this is a limitation of the way mIRC handles sockets. If you don't process the UDP packet before another UDP packet is received, you will lose the information about the UDP packets prior to the most recently received.

Hum, you might be right, but :
I think this is wrong, why would it work with another delay ? The event triggers twice whatever the order of the packet, in both case the last received udp packet is the one I want to play with but the source port is the same, and in my case it's the same ip too, how to send an information to the right person ?

If I specify the local port to use, with a function like this:
it work perfectly, and this is what I expect when not using a local port

the event triggers twice because you didn't read all the data from the receive buffer the first time: $sock().rq would probably reveal that there is more information to read. i say 'probably' because if you try this test many times, you're bound to get 'correct' results at least some of the time.

as drum said, it's just the way UDP works :P you can't guarantee that the data in the receive buffer came from multiple sources at the mIRC level, and i don't think it can be done seamlessly at the C level either (if we assume that the application polls the system for new incoming data - the two datagrams you send may be received by the system in between polls).

you could have the clients encode all details that could potentially be lost as the first few bytes of every message.

This is actually a regression.

I see the correct separate source port numbers when running the code in mIRC 6.35.

If there's a design limitation in the way mIRC reads sockets, it's been introduced recently, and I can confirm that this is a bug-- a fairly serious one, since it means a script cannot properly respond to a client if multiple clients send data at the same time. Data can leak from one connection to another-- especially since this bug likely applies to the source address too. Again: this bug means that a malicious user could easily steal response packets from any mIRC UDP server script simply by flooding it with garbage packets while other clients interact with the server normally.

For reference, wireshark shows the following:

7 219.155133 192.168.0.2 192.168.0.2 UDP Source port: 65050 Destination port: vcom-tunnel
8 219.155320 192.168.0.2 192.168.0.2 UDP Source port: 65051 Destination port: vcom-tunnel

mIRC *is* actually sending the packets on separate ports. The problem is indeed that the sockread event is tripping over itself.

I doubt it could be done "easily," but it certainly sounds like it could be exploited. The reason these UDP packets arrive so closely together is because the source and destination are the same machine for both packets. Introducing any amount of latency through a network would probably make it considerably harder to replicate but it definitely is possible.

Honestly, I think the way mIRC relies on a $sock() call to retrieve things like the remote IP and port is flawed from the beginning. Instead of simply trying to patch this bug (especially if it ends up being a convoluted bug to fix), I think it would be far more appropriate if mIRC delivered the information directly to the event as locally-scoped identifiers. For example, a UDP packet's source IP ought to be passed to the event in the form of something like $saddr instead of having to use $sock($sockname).saddr. I'd like to see this extended to all of the relevant $sock() calls (for TCP connections, too), but at the very least, to .saddr and .sport.

I did read all the data, try it because I did test this many times, and the bug occurs 100% of the time.No it's not how udp work, thanks god in C you can accuratly get the source ip and port.

??

Yep, must be related

you used /sockread -n which will only read the first line from the receive buffer. try this:



if you repeat your tests you will probably notice, as i did, that the event mostly triggers only once with $sock().rq = 10. this implies that both lines are being put into the receive buffer before on UDPREAD has a chance to trigger, and $sock().sport will quite rightly return the address of the sender of the last received datagram.

the issue is why mIRC isn't triggering on UDPREAD fast enough for the scripter to be able to distinguish between two distinct datagrams from two different senders.



i've never used UDP in C so i referred to the Berkeley socket API (on which Winsock is modeled) as in another thread concerning accept() with TCP sockets. and, like that issue, it was revealed that the limitation was inherent to the API rather than mIRC's own implementation:

http://en.wikipedia.org/wiki/Berkely_sockets#Server_2

the infinite loop at the end shows that the application is polling the system. i'm not sure if it's sensible to assume that multiple datagrams could be received in between polls - notice how the article prefaces its example with a word of caution as to its reliability in various ways - but it would certainly explain mIRC's behaviour. EDIT: disregard, this is nonsense



if destination IP address and port is important and is being lost frequently then encode them into the message. a naive way to do this would be to use the first 4 bytes for the IP and the next 2 for the port.

Not really. 2 independent packets can arrive closely together in any order-- the fact that there's no latency locally is irrelevant, because it doesn't matter how long it takes the packet to arrive, it only matters how long mIRC takes to *read* the packet queue. If you saturate the receive queue of a machine so heavily that the vast majority of the packets are yours, eventually you will get such a collision-- it's basic statistics. Even if only 1 of every 100 packets got hijacked, that would be significant after a very short amount of time. Also realize that in a real world scenario, both clients would be remote, so the local thing doesn't apply anyway. It would be fairly easy to write a proof of concept for something like this.



Nothing is flawed, because it worked fine before. This is nothing but a regression. The design of the system is fine, and there's no need to break backwards compatibility and change functionality now. In any case, there's also no reason to add bloat by creating extra event-specific identifiers when a socket-specific identifier makes perfect sense in a single-threaded environment. In a single-threaded environment, per-socket data is *equivalent* to locally-scoped data.

Ah, I see your point now, maybe it could be improved to speed up the triggering part

You have a fundamental misunderstanding about how UDP works, and it looks like mIRC now gets it wrong, too.

UDP is a datagram-oriented protocol. Datagrams are individual units, each with their own source IP+port, destination IP+port, and payload. As far as the application can see, they are never combined or split up. Hence, "on UDPREAD" should trigger once per datagram, and it is then up to the script to process as much as it wants from that datagram. All the while, $sock().saddr/.sport should return the source IP and port of that diagram. If two datagrams are received, "on UDPREAD" should trigger twice.


Each recvfrom() call will return up to one whole datagram, no matter how many datagrams arrived before it was called. The word of caution relates mostly to the behavior of the underlying network, not to the behavior of the operating system; the only possible concern is that if the application is not fast enough in processing the incoming datagrams, the operating system may decide to throw away some of them. None of that is relevant to this problem.

Yes, this is a real bug.

When I say it is "flawed," I mean that it is more complicated than it needs to be. I also think it is confusing. After some more thought, I think I have reversed my opinion on the TCP-related calls. It makes sense that the remote IP and port aren't going to change during the course of a TCP connection's lifespan, so $sock().ip and $sock().port seem like reasonable ways to deal with TCP sockets.

However, the issue with UDP sockets is that each datagram will have a potentially different remote IP/port associated with it. In this manner, the $sock().sport and $sock().saddr information isn't actually tied to that socket name (since you can receive datagrams from multiple sources on that same socket name); instead, that data is tied to the individual datagram. This is why I think it makes more sense as a locally-scoped identifier for the UDPREAD event.

Ultimately, I think $udpaddr and $udpport from within the scope of ON UDPREAD make more sense in that it emphasizes that this information is only valid for that particular datagram and not for the socket in general. It may not matter in terms of functionality but it does seem like a more LOGICAL way to design it. It also seems possible (although I can only guess because we don't know the true cause) that the bug being discussed in this thread might not occur if the IP/port information was passed directly to the event instead.

Along the same lines, I'd like to see something like $sockip and $sockport in ON SOCKLISTEN events, to be able to access the remote IP/port that is connecting before accepting the connection.

This was discussed in a feature request thread a few weeks back. I don't claim to really understand everything said in that thread, but it was explained that this is not possible. Basically, you don't receive that information until the connection is made. You can probably find the thread in the first page or two of the feature request forum.

It is possible to access the information via the 'conditional accept' mechanism, which was pointed out in the thread you're talking about. There appear to be some drawbacks to this though, at least on Vista upwards.

I understand what your view is, and for the most part I agree-- but I still don't think there's any reason to introduce a new API when there is an existing one that works fine. Just like many other features in mIRC's language, you tend to have to abandon the "conceptually ideal" solution for the "it works" solution.

For reference, the reason $sock().saddr/sport were used were likely for consistency's sake. Introducing a $udpaddr and $udpport would be *more* confusing, since there would be no related $tcpaddr and $tcpport for the TCP events. On the flipside, most scripters are looking to $sock() to get information from the socket, and there is no precedence for event specific identifiers in SOCK* events. It would be confusing as well, in this sense, to introduce event specific identifiers for one thing when virtually everything else is tied to $sock(). IMO it makes sense here to break the conceptually clean design in order to maintain consistency.

After some test, there is another problem, sometime the on udpread event (still) doesn't show any source ip or source port.

Thanks I was able to reproduce the issue with saddr/sport not being correct in situations where multiple /sockudp commands are issued at the same time. This has been fixed for the next version.

Thanks