i'm working on a NAT server in pure XDP. but to have a robust nat functionality i wanted to track the connection (storing and fetching tracking data) and i was thinking about using the already exist netfilter conntrack data structure and functions to help with packet processing in XDP, i have some knowledge about nf_conntrack but i feel i miss something, i'm not sure exactly if i can just recieve the packet and check with netfilter conntrack if it's a new connection or not.
for example if it's a new connection :
i can just call a netfiler conntrack function which can make decision about what port i can assign as public source port and another info to a tuple.
and when the reply back i can check in nf conntrack that it's a reply and just update the packet info and pass to the internal network.
i got some inspiration from this repo : https://github.com/ti-mo/conntracct. but i see they doing only statistics, so here the packets go through the normal kernel stack.
i feel confused a little but if i managed to explain what i'm thinking about and you have a hint or a tip to direct me, i'd be grateful.
thanks.
The XDP program execution is one of the very first things that happens for received packets, so conntrack didn't occur yet at this point. There's also no BPF helper that implements the conntrack behavior out of the box.
If you want to track connections at the XDP hook, you'll have to implement your own conntrack logic in BPF. It's what Cilium does for example.
Related
I am new to GNU Radio and Linux.
I want to send processed data out from gnu companion to a software/dashboard whose input is LAN/TCP/IP.
I am using RTL dongle and USRP and i have done GMSK demodulation successfully.Now want to send the demodulated data to a software for presentation and display developed by another team.The dashboard/software uses Ethernet data as input and has ip address and port as input parameters.
Currently i failed to send a random data via TCP sink and receive it via TCP source blocks on loopback address.
Please help me
Did you set the TCP Sink to "Server", and the Source Block to "Client"? Only the block that is set to "Client" needs to know the address, but both need to know the Port.
And is the port you use for your loopback test free, or could another program be using it?
Also, if the Nonblocking mode for the TCP blocks is off, the execution of the flowgraph is halted until a connection is established. I’m not sure but I think that could lead to problems if they are supposed to connect to each other in the same flowgraph.
Try using an external program (like netcat) for debugging instead. netcat will probably not display it correctly but it’ll tell you if any data at all is coming through.
Additionally, the TCP source and TCP sink blocks are deprecated and shouldn’t be used, use UDP or ZeroMQ for communicating with external programs instead, if possible.
(Remaining segment of original Question)
I'm a bit confused on logistics of a software firewall app on a client side computer that blocks incoming on a port. Texts generally depict a Server initiating the bind to a port then setting up listening. Then clients can attempt to connect to this server, upon which the Server assigns the Client another free port number to form the connection protocol tuple.
But how does an app on a client setup or bind to a port to monitor and/or block it?
UPDATE EDIT ADD:
I looked at the links 4dc0 gave in comment and they were helpful.
So I deleted certain segments of my original question as answered to a point that they are mute issue of concern.
After doing more reading I found in the context of servers, 0.0.0.0 means all IPv4 addresses on the local machine. So this led me in a new direction of decipher.
so I looked at this, >netstat -a -n -o -b
I like the -b switch cause some PIDs don't show in task man svcs.
Proto Local Address Foreign Address State PID
TCP 0.0.0.0:49168 0.0.0.0:0 LISTENING 2020
listening
[NortonSecurity.exe]
TCP 0.0.0.0:49169 0.0.0.0:0 LISTENING 2020
[NortonSecurity.exe]
TCP 192.168.1.5:49170 13.91.60.30:443 ESTABLISHED 2020
[NortonSecurity.exe]
TCP 192.168.1.5:51220 50.23.246.167:80 TIME_WAIT 0
TCP 192.168.1.5:51223 151.101.1.69:443 ESTABLISHED 5504
[firefox.exe]
This was interesting but I still needed help deciphering the full impact. I did more searching and found this link,
How do multiple clients connect simultaneously to one port, say 80, on a server?
While a different Title persey it gave me a lot of insight into this and more directions to search from here. Additionally it gave a good book link which in the used sellers section was affordable.
I can see many reasons why someone qualified would not reply to a post like this. However my naivety in posting the question was surpassed only by my desire to get more insight into these facets. Admittedly I was not seeking to write code for such, but desired a deeper understanding of it. As I searched through one clue to the next I realized the depth and scope of what I sought. And after some effort I did find enough to give me an idea of what's going. In case anyone comes by here with same curiosities I'm posting up a few of the better links I found.
Some links are dated but contain paradigm related content of application based filtering, tracking, layer 3, 4, and/or drivers via the NDIS firewall paradigms.
https://www.symantec.com/connect/articles/software-firewalls-made-straw-part-1-2
https://learn.microsoft.com/en-us/windows-hardware/drivers/network/ndis-driver-stack
https://learn.microsoft.com/en-us/windows-hardware/drivers/netcx/
https://www.codeproject.com/Articles/3405/Developing-Firewalls-for-Windows-2000-XP
https://www.codeproject.com/Articles/5602/Simple-Packet-Filter-Firewall
https://www.novell.com/documentation/nbm38/?page=/documentation/nbm38/overview/data/ae70q0b.html
http://programmerworld.net/personal/firewall.htm
Good recommended book
https://www.amazon.com/exec/obidos/tg/detail/-/0471205443/qid=1094828844/sr=1-1/ref=sr_1_1/103-9352427-0026242?v=glance&s=books&tag=hardfocom-20
I'm currently implementing my first application in Contiki on a Telos bmote and encountered a problem.
For my application (which utilises the uIP IPv4 stack) I need to be able to broadcast messages to all nodes.
I have looked through the source and found that in uip_over_mesh.c the packet is found to be for an external network and is then being sent to a gateway node on the network instead of being distributed to all nodes. If no gateway node is present it just drops the packet.
So in fact rather than the packet being broadcast to all the nodes in the network it's either just being dropped or being sent to just the gateway node and external network.
My problem is that I need it to broadcast to the other nodes in the network(as it should), is there a step I'm missing or am I doing something wrong?
Thanks :)
p.s. This is the rough code to get the message to send.
struct uip_udp_conn *udp_conn = udp_broadcast_new(UIP_HTONS(5001), state);
udp_bind(udp_conn,UIP_HTONS(5001));
uip_udp_packet_send(udp_conn, "hello",5);
Sorry that my question didn't seem clear. To clarify what I wanted to do was send an IPv4 UDP packet to the broadcast address i.e. send to all devices on the network using the all ones addr. But I found that the sending device would only forward the message to a gateway node if it was present on the network.
The question is not clear but what I understand from the question you want to broadcast a message anonymously to all neighbour motes. You have two choices to go.
If you are using RIME stack from contiki. There is already a code under example/rime/example-broadcast.c (have a look at line 79,80 ( packetbuf_copyfrom("Hello", 6); broadcast_send(&broadcast)); I have tested the code and it is working perfectly fine under teleosB. I strongly recommend you to go with uIP (IPv6) stack using RPL. For a large network it 'll be extremely hard to maintain rime stack.
You can use udp based ipv6 enable broadcast example from examples/ipv6/simple-udp-rpl. You do n't need to change anything for receiver function unless you want more additional features. This function 'll print receiver port, sender port and data length. You can add "addr" from "uip_ipaddr_t" in the receiver function if you want to print IP addresses. For sender the lines of code are (76-91). You do n't need to change for simple message like "hello". I tested the code and it works perfectly fine.
After lots more reading of the Contiki source I found that the problem lay in uip_over_mesh.c.
When a broadcast message(255.255.255.255) was being sent it was tripping up when the send function would check if the destination was within the local network (based on the netmask and destination address). Failing this it would then try to send it out to a local gateway(if one existed) to route it out of the network.
Although IPv4 UDP broadcast had been built into the api, I saw no evidence of it actually being implemented in the uip_over_mesh.c(I might be wrong and totally missed it). So to fix this I added a broadcast RIME channel and added a check for the all ones address where the previously mentioned gateway check was. A method to receive the broadcast messages was also implemented ensure broadcast message were correctly received and passed to the upper layers.
From what I gathered from here and the mailing list, IPv6 is where the focus is and not many people are knowledgeable or using the IPv4 uip stack. When I get some time I will dig up my modified uip_over_mesh.c and see if I can push the modifications, though I'm sure it's a bit of a hack and not of much use due to the above mentioned lack of interest.
I'm writing a dissector for a protocol that I have to work with. This protocol runs atop TCP and is stateful.
In order to dissect the fields correctly, I need to identify which endpoint opened the TCP connection (the client).
Is there a way to get this info from the tcp dissector? Would I have to write a tap? I'm not so clear on how to do this in lua.
Cross posted on the Wireshark stack site here.
To write stateful protocol dissector in Lua you can use closures to store state information.
you can easily decipher which endpoint started conversation if you analyse flags SYN/SYN+ACK for the first packets of given TCP stream # (which is generated by TCP dissector).
To make this work you should install a post dissector and check for 'tcp.stream' field.
You can checkout that technique in sources of my small Lua wireshark dissector to capture HTTP state information
Hey SO,
What examples do you know - of protocols initially "handshaking" in UDP, then "conversing" in TCP.
I know there are heaps, I just can't seem to think of any right now.
Specifically, I'm trying to write a Wireshark dissector - for this kind of protocol.
So being able to peek on a similar dissector, seems like a good start.
Would love to hear if you've ever written a stateful Wireshark dissector in LUA.
One example is SIP/Fax.
SIP/SDP setups the session for fax transmission, and then transfers fax/image via TCP/TPKT.
There are several that use both UDP and TCP (see Apple's list, marked as TCP/UDP), but I don't know if they behave exactly as you've described (initial handshake with UDP). DNS and NFS are a couple examples.
I've written Wireshark dissectors in Lua, but not stateful ones.
Surely a handshake would be in TCP being a stateful connection? A handshake seems like something that would want to be ordered, compared to UDP where there is stateless transmission?
I've added some kind of statefulness for the HTTP protocol within my project aimed to lookup original HTTP request for given HTTP response.
Generally speaking, Lua has nice notion of closures which can be used as kind of static global variables for holding handshakes and whatever other references.