I've just installed pfSense (a FreeBSD distro) and I'm having problems with my Ethernet adapters - I seem to be able to get it into a state where I cannot ping any machine despite the ARP tables etc... all being correct (On the machine I'm pinging I can see the packets arrive and the response sent in Wireshark, but the remote machine gets nothing)
Having an interest and limited knowedge in OS development I kind of want to have a go at debugging this, but in many ways I'm not really sure where to start:
How do I go about getting the source code for the drivers I'm using? Will they be part of the FreeBSD source code, or is there going to be some external project? (or are the drivers I'm using likely to be the proprietry ones released by Realtek, and therefor not have source code)
For that matter, how do I identify what drivers I'm currently using?
Finally, are there any good resources on how to debug Kernel-level / device drivers?
(I appologise if I'm asking silly questions or if I seem overly optimistic about what I'm hoping to achieve by debugging this, but although I lack experience in this area I consider myself to be a smart guy and I've gotta start somewhere!)
I really doubt your problem is in the device drivers or other kernel code. Check the PF rules - you most probably just dropping all ICMP packets out right.
Related
I have tried using ESP-CoAP but the coapclient.ino example does not work for me. The server in this example is 129.132.15.80. Is there any other server I can use to test my code? I have also tried coap.me but this code only accepts IP addresses. Are there any alternatives to this library that are regularly maintained?
About the question for test-servers:
Many OS offers you a way to resolve a address as "coap.me" to their numeric address (e.g. unix nslookup coap.me => 134.102.218.18). The open source project Eclipse/Californium offers a sandbox as well (nslookup californium.eclipseprojects.io => 104.196.15.150). You may also try to run Californium's Plugtest Server locally (requires installed java).
In all cases, it's a good idea to get common with ip-capture tools as tcpdump or wireshark. A very first introduction may be found here
About the question for maintained c-implementations:
libcoap is a very common one. But I don't know, if there is a "out of the box" ESP 32 port available.
[I had to repost this from the ask.wireshark.org as my questions do not come up there, still not sure why].
Hi All,
I'll try my luck here.
I'm trying to solve a similar problem to the one described in "how to work around unicast messages" question, albeit in my case I'm not seeing an ARP reply (unicast) in Wireshark.
I need to say that I have read everything that was suggested in that thread (wireshark help and a set of other documents on Ethernet Capturing/Hubs vs Switches vs Taps, etc.) and still puzzled, so basically would love to hear any ideas thrown at me by experts.
So:
it is Ethernet;
3 devices:
1. a custom device (running embedded linux)
2. a PC (WinXP) where wireshark is running (promiscuous mode, capture all)
3. a PC where a server application is running to which the custom device communicates.
all 3 connected to [what is believed to be] a simple hub "CentreCom MR415T repeater" 10BASE-T only (not dual speed).
I'm seeing all the traffic I expect to see in Wireshark but NO ARP replies (unless they are sent to the Wireshark PC).
For the problem I'm trying to nail it is crucial to tell whether there are NO replies to ARP requests sent by custom device (1) or it (the device) is unable to correctly handle these replies (which is quite possible).
All other symptoms point to the latter but I need to actually SEE and be able to SHOW this as a proof.
Thanks in advance to anyone who replies,
Alexei
UPD. 2016/06/09: In advanced settings of Panda Firewall found a tick box "SmartARP" - unticked and this solved the issue.
The ultimate reason of not seeing ARP replies in Wireshark turned out to be: Panda End Point Protection Plus Firewall. Not the most flexible piece of software as far as I can see, creating a User rule for Wireshark to allow both incoming/outcoming does not help in the slightest, but disabling the firewall - does.
Background: I'm a fourth year computer engineering major at UCSB. I've taken networking and operating systems courses. I created a program in userspace that broadcasts UDP packets onto the subnet and receives UDP packets in an adhoc network. What I'm trying to accomplish is to convert this program into a kernel module that will work on an ARM embedded system with Angstrom Linux, kernel version 2.6.39 (the x86 to ARM architecture cross compilation is an issue for another day). The reason for this move to the kernel is to shed some of the overhead of userspace functions and to make the sending and receiving part as quick as possible.
I've never done anything like this before in any of the courses I've taken, so please tell me if anything I am saying is incorrect, useless or inefficient!
After research with Google, I've concluded the typical way is to do away with sockets entirely and work with the sockbuf structure and fill in the necessary headers myself. Would this have an effect on the ability to broadcast packets on the subnet?
I am currently trying to follow the code here:
UDP packet send with linux-kernel module without using sockets
I've figured out the reasoning behind most of the code, but the last part is what confuses me:
eth = (struct ethhdr *) skb_push(skb, ETH_HLEN);
skb_reset_mac_header(skb);
skb->protocol = eth->h_proto = htons(ETH_P_IP);
memcpy(eth->h_source, dev->dev_addr, ETH_ALEN);
memcpy(eth->h_dest, remote_mac, ETH_ALEN);
skb->dev = dev;
dev_queue_xmit(skb);
All of the ethernet header seems to be constructed purely out of headers defined in the kernel besides the source MAC address, is this correct? I am going to be broadcasting my packets, so what exactly should be put into the destination MAC address field?
More importantly, what is dev in the skb->dev = dev; line? From my investigation, it is a pointer to the device driver it is associated with. From my understanding, I would want this to point to the wireless chip device driver as I am using 802.11 to communicate. Do I have to create my own dev struct for the wireless driver? If so, there any guidance on how to accomplish this? If not, how can I access the existing device driver and use this in a kernel module?
I've tried commenting out the dev line and running the code but unsurprisingly I get a kernel panic once it executes dev_queue_xmit(skb);.
Again, I've never done anything like this before, so any advice would be helpful, even if it means changing my approach entirely! I also understand that this could be a niche of a question, but any sort of guidance is appreciated!
Thank you in advance!
The best way is not to interfere with the protocol if you are not trying to modify one. Work on a higher (socket) layer. This API can be found in net/socket.c
This will help: (open in new browser tab/window to zoom)
I am aware that there are programs out there like lojack for laptops that get installed on the BIOS, but I'm still a little confused. When reading about lojack, it seems to me that they can't fully located the laptop's location until the user logs in and tries to access the internet. So I'm thinking that it's a BIOS application so that it wouldn't matter if the thief reformats the HD.
So my question is, does anyone have any ideas of how an internet enables BIOS application would be written. I'm not looking for full answers -- just ideas or resources to get started. For example, is such a thing written in assembly? Once one such app is written, how does it get transfered to the BIOS.
Does the BIOS program itself recognize that there is an internet connection (when the thief logs on to the OS). Or upon logon, does additional processes get spawned? Are there any resources/websites that anyone can direct me too?
You didn't mention whether you were interested in legacy BIOS or EFI BIOS, but I would mention that with EFI there is the capability of writing EFI applications. See Intel Press:
Harnessing the UEFI Shell
The EFI Application toolkit comes with a complete TCP/IP network stack:
http://www.intel.com/technology/efi/toolkit_overview.htm
More at tianocore.org
Regarding "LoJack"-style solutions, one of the providers of this technology is Absolute Software's Computrace product.
Basically there are 3 components: 1) a software component that runs in the OS; 2) a BIOS component which is baked into the system BIOS (accomplished via Absolute working with the PC vendor); 3) servers at Absolute software that talk to the PC.
For more information on how it works visit:
http://www.absolute.com/en/company/Computrace-Persistence.aspx
(see especially the demo video on this site)
To learn something about BIOS, one good source is coreboot.org. It is an open source BIOS (or firmware) and support some physical machines.
Legacy BIOS is written in assembly language, but new generations, such as UEFI or coreboot, are written mostly in C language. BIOS program is stored in the ROM, and executed by the CPU automatically.
The BIOS program itself does not access the internet or perform any of the advertised functions. The LoJack addition to the BIOS firmware is a file copying/patching utility - at boot up it can check the harddrive for a copy of Windows and proceed to silently install/repair the LoJack service if it has been removed. The service itself includes several measures to lower it's profile and prevent itself from being disabled (similar to how many trojans and malware run several processes that each restore the other if one is disabled or killed).
The LoJack BIOS program can't do anything if a unsupported operating system (like Linux) is installed after the harddrive is wiped.
Is it possible to emulate incoming messages using Indy (if it's of any importance: I'm using Indy 10 and Delphi 2009)? I want to be able to create these messages locally and I want Indy to believe that they come from specific clients in the network. All the internal Indy handling (choice of the thread in which the message is received and stuff like that) should be exactly the same as if the message would have arrived over the network.
Any ideas on that? Thanks in advance for any tips.
What you want to do has nothing to do with Indy, as you would need to do this on a much lower level. The easiest way to make Indy believe that messages come from a specific client is to inject properly prepared packets into the network stack. Read up on TCP Packet Injection on Google or Wikipedia. EtterCap is one such tool that allows to inject packets into established connections. However, this is definitely going into gray areas, as some of the tools are illegal in some countries.
Anyway, all of this is IMHO much too complicated. I don't know what exactly you want to do, but a specially prepared client or server is a much better tool to emulate certain behaviour while developing server or client applications. You can run them locally, or if you need to have different IP addresses or subnets you can do a lot with virtual machines.
Indy doesn't have any built-in mechanisms for this but thinking off the top of my head I would recommend building a small test application (or a suite) that runs locally on your development machine and connects to your Indy server application to replay messages.
It should be irrelevant to your Indy server applications if a TCP connection is made either locally or from a remote host as the mechanisms by which a server thread is created and a command processed is identical to both scenarios.
My last gig involved using Indy and all our testing was done with a similar Resender type application that would load local message files and send these to the Indy server app.
HTH and good luck!
One thing you can do would be to create virtual machines to run your test clients, that way they will not be seen as "local machine", and its fairly simple to create a complex network with VMS -- provided you have enough memory and disk space. The other advantage of testing with VM's is you can eliminate the development environment completely when its time to focus on deployment. Amazing how much time that saves alone.
VirtualPC is a free download from Microsoft and works fairly well. VMWare has another option, but costs a little more to get started. For development purposes, I prefer the desktop versions but the server versions also work well. You will still need to have a license to install the virtual OS. MSDN membership is probably the cheapest way to go, and allows you to build test environments for other flavors of the OS.
Indy has abstract stack mechanism for crossplatform support (IDStack.pas) I think u can hack the stack for windows (IdStackWindows.pas). It is a class. U can even consider to derivate it and override some functions to do the hack.