Tasp
Full Member
Posts: 215
|
Post by Tasp on Feb 7, 2020 14:46:25 GMT -5
If you've downloaded python instead of getting it from the app store it acts differently.
Once you install it from the app store you can use the pip installer.
|
|
|
|
Post by Rod on Feb 7, 2020 14:50:06 GMT -5
I got it from the app store
|
|
Tasp
Full Member
Posts: 215
|
Post by Tasp on Feb 7, 2020 14:51:05 GMT -5
This can help with installing pip link |
|
|
|
Post by Chris Iverson on Feb 7, 2020 14:56:23 GMT -5
Rod: pip is run from the command line, not inside of the python interpreter.
C:\Users\Chris>pip install udp-test
As for why it's not working for you, Tasp, I honestly don't know. It's not something I would expect, especially if it's the same code.
|
|
Tasp
Full Member
Posts: 215
|
Post by Tasp on Feb 7, 2020 15:03:36 GMT -5
OK,so if I run the UDP-test python test server, it receives data from LB, but it looks like a completely different port? Assuming it is showing the port number on the python script.
Wireshark shows nothing actually happening on the port, this maybe at it's not actually going across the NIC ?
However, since it's UDP, why must it have something to connect to, I was under the impression that UDP didn't care and just sent it anyway?
|
|
|
|
Post by Chris Iverson on Feb 7, 2020 15:30:26 GMT -5
Hi Chris, I too tried your code with the Windows app, and got similar results to Rod. The Python script recieves the message from LB, but LB does not recieve a reply, as far as I can tell. It just sits there and waits. That's strange, I don't know why it wouldn't receive the response, if the first message got sent successfully. The python script prints the following message on the console "got a message from 127.0.0.1 : 52676 ==> myDataKDFSLKE" . I do not know where that port number came from, obviously it is not in the LB program. OK,so if I run the UDP-test python test server, it receives data from LB, but it looks like a completely different port? Assuming it is showing the port number on the python script. I'll answer both of these at the same time, since it's the same basic question. The port number that's shown in the python script is correct; it's where the data is coming FROM. You see, ANY IP connection, TCP or UDP, requires a port on BOTH sides of the connection. 50000 is the port on the LISTENING side; there's also a port that gets opened by LB on the sending side to actually send the data. Outgoing ports are usually not specified by any program, and they leave choosing a port up to the OS(since the OS knows which ports are available to actually bind to). The port that you see listed by the python program is the port the data came from. Wireshark shows nothing actually happening on the port, this maybe at it's not actually going across the NIC ? However, since it's UDP, why must it have something to connect to, I was under the impression that UDP didn't care and just sent it anyway? It's quite possible that's the case, loopbacks normally don't hit the NIC, and get processed by the driver directly. This is problematic for Windows machines, as you can't use packet sniffers to capture loopback data directly. The wireshark guide does provide an option to be able to capture traffic sent over the loopback interface. wiki.wireshark.org/CaptureSetup/LoopbackYou can also try specifying your local IP address instead of the localhost/127.0.0.1 loopback, as sometimes that's enough to get it to be seen by wireshark. (This won't always work; sometimes the driver is smart enough to know that the destination IP is the local one, and will route the traffic over loopback anyway.) When opening Wireshark for capture, check to see if you have the "Adapter for loopback capture" available. Also, if anyone's having trouble getting send to go through at all, sometimes different IP addresses will work, like 127.0.0.1 or your actual local IP address. Sometimes programs "listen" on different IPs. However, as to your "why does it care", that's a very good question, and why I'm confused as to how sending the data is failing for you. The server is only set up so you can actually see the data is being transmitted. It shouldn't matter if it's actually there listening, the datagram will be sent to the void and nothing will pick it up. In fact, if I send the data out without setting up the server, I get the same success code. |
|
|
|
Post by colinmcm on Feb 7, 2020 16:01:46 GMT -5
Hi Chris,
your code did work for me for both sending and receiving. I misread the results, my programmimg skills are a little rusty.
Colin
|
|
|
|
Post by pandawdy on Feb 7, 2020 17:20:08 GMT -5
I really hope that in time UDP / TCP functions are added to Liberty Basic. I know Carl is extremely busy but I have my fingers crossed.
|
|
|
|
Post by Chris Iverson on Feb 7, 2020 19:11:14 GMT -5
If you still can't get that working for what you need, Tasp, I'll see what I can do about getting UDP added to my DLL. I need to finish working on that and release it, anyway. It's pretty much feature complete for the current features I want in it.
|
|
|
|
Post by Rod on Feb 8, 2020 4:41:04 GMT -5
Ok, so if you are new to Python its not the IDLE, its not Python3.x it's plain old windows command prompt that the commands get entered in. Running the Python script I get Chris's code to send the message. Its not clear to me what is coming back but I sure it will be working.
However I have tried two different apps from the Microsoft store. Both fire up and appear to be listening on port 50000 but they never get the message.
One thing that did happen is that Python woke up the firewall dialog and I had to give it permission to allow access. Neither of the store Apps asked for that.
|
|
|
|
Post by Rod on Feb 8, 2020 8:58:28 GMT -5
OK, I have dumped the two apps I got from Microsoft Store. Both would not listen. The firewall was open but they never received anything and even trying to make them talk to each other resulted in crashes.
I am having much better luck with a tool called UDP Test Tool 3.0 With that I can open a Host and listen and receive messages from both Chris's Liberty code and the software's own remote client tool.
So I can now send a stream of UDP messages. I have not got the send and receive working yet, the host reissues nothing as yet and the code times out. But I can see how I should tweak the code. Off to learn a little more about UDP and play with some Liberty code.
Amazing that such a small amount of code opens such a huge doorway! Thanks Chris.
Edit to add localhost did not work, neither did 127.0.0.1 I had to use my local ip found via the command line and ipconfig.
|
|
Tasp
Full Member
Posts: 215
|
Post by Tasp on Feb 8, 2020 13:44:42 GMT -5
If you still can't get that working for what you need, Tasp, I'll see what I can do about getting UDP added to my DLL. I need to finish working on that and release it, anyway. It's pretty much feature complete for the current features I want in it. Chris, if you need that functionality, then please add it to your DLL! At least we know that, it will be compatible with LB! I don't wish to be cheeky, but do you have an ETA? If I use either loopback (127.0.0.1) it shows nothing in wireshark, so as Chris previously said this is likely to be the drivers not routing it thru the NIC. If I put the remote IP address I do see transactional data in wireshark. However, the code below refuses to receive anything from my external device (which does show traffic in wireshark). It does however receive ok when using the python UDP server (posted above). Warn: This code loops 10 times with a 2500 wait cycle
GLOBAL port, b, address$
address$ = "localhost" '"192.168.0.174"
port = 10002
Call NetInit
print "NetSetUDP: ";NetSetUDP()
hSock = NetOpen(address$, port)
print "hSock: ";hSock
FOR b = 1 to 10
a = NetSend(hSock, STR$(b))
print "NetSend: ";b
print "interation: ";b
print "Recieved: ";NetReceive$(hSock)
next
a = NetClose(hSock)
print "NetClose: ";a
call NetTerm
Sub NetInit
open "mesock32" for DLL as #me
End Sub
Sub NetTerm
close #me
End Sub
Function NetSetUDP()
NetSetUDP = NetSetOption(1)
End Function
Function NetSetTCP()
NetSetTCP = NetSetOption(0)
End Function
Function NetSetOption(opt)
Calldll #me, "TCP_SetOption",_
opt as long,_
NetSetOption as long
End Function
''''Function TCPOpen()''''''''''
Function NetOpen(address$,port)
Timeout=2500
print "port: ";port
calldll #me, "Open", address$ As ptr,_
port As Long,_
Timeout As Long, re As Long
NetOpen=re
End Function
''''Function TCPReceive$()''''''''''
Function NetReceive$(handle)
buffer=4096
all=0
calldll #me, "ReceiveA" ,handle As Long,_
buffer As Long,_
all As Long, re As long
if re<>0 then NetReceive$ = winstring(re)
End Function
''''Function TCPPrint()''''''''''
Function NetSend(handle,text$)
calldll #me, "SendA", handle As Long,_
text$ As ptr,re As Long
NetSend=re
End Function
''''Function TCPClose()''''''''''
Function NetClose(handle)
calldll #me, "CloseA",handle As Long,_
NetClose As Long
End Function
Having IP data functionality within LB4 opens a few new doors. Would be really handy if you manage to get something working Rod. |
|
|
|
Post by Rod on Feb 8, 2020 13:51:32 GMT -5
Just to add, firewall must be an issue. I am now working with two PC's on my home network, each has its own local IP.
Both PC's will allow "on PC" messaging to the local IP but only one, thus far, will allow messages between PC's
So I can happily send messages from the first PC to the second PC but not from the second to the first. So it has to be firewall because all the code is identical. More to research.
|
|
|
|
Post by Rod on Feb 8, 2020 14:02:10 GMT -5
Tasp If I run your code with my local IP (localhost does not work) it sends the initial message but since I don't send a response it seems to stop. If I remove the read part from the loop it works perfectly well and the ten messages are sent. I have one PC running your code and the other PC running UDP Test Tool as host with the IP set to the machines local IP and the port set to 55000. But as I said at the moment I can only go one way. NetSetUDP: -1 port: 55000 hSock: -4 NetSend: 1 NetSend: 2 NetSend: 3 NetSend: 4 NetSend: 5 NetSend: 6 NetSend: 7 NetSend: 8 NetSend: 9 NetSend: 10 NetClose: -1
|
|
|
|
Post by Chris Iverson on Feb 8, 2020 16:27:44 GMT -5
Chris, if you need that functionality, then please add it to your DLL! At least we know that, it will be compatible with LB! I don't wish to be cheeky, but do you have an ETA? ETA is "now", due to me becoming super absorbed in the project and accidentally working until almost 4 in the morning on it. It's amazing how much fun I can have writing code. This is my LB-Schannel-Wrapper DLL, but I've renamed it to "LBNet", both because of the simpler name and because of the fact that it's become a general networking DLL, and not just an encryption DLL. You can download a UDP release(fully-functional DLL, but only includes example code for UDP stuff) on this page: github.com/iversc/lbnet/releases/tag/2.0.0-RC1Example code for other things(TCP and TLS-encrypted TCP) can be found in that repo, but I think I want to try to clean it up and reorganize it before giving it an "official" release. It should all work just fine, though. Admittedly, the code to use my DLL looks a bit more complicated, but a lot of it is just error-checking. There are a couple complicated things, but the benefits for that complication include actually being able to host a server(the mesock DLL seemingly can, but it requires hooking into a window with WMLiberty, and I've not actually been able to get it working, due to lack of documentation), and being able to send ANY data, and not just ASCII data. (The mesock DLL would corrupt anything in binary form you tried to send). |
|
