Bare with me I'm new.
Whilst researching the input event system in the kernel, I came across the need to access the input handlers that have already been registered with an IRQ lane given only the irq lane (just the integer). Is there a method to access ALL event handlers associated with an IRQ? I am looking to map each list of handlers from a given input device (say mouse) to each possible event that the device could make.
Related
OK this might be in the wrong place if so sorry, however might be of use and maybe can be used to dev some work arounds when tethering...
Intro seemingly ATT US have started to spot people who are tethering BUT not on a data plan that "alows" tehtering (we can argue the rights and wrongs of that but this isnt about that issue)
People where asking about how they could tell, I found the following on The Register
QQQ
For all you wondering how they can tell:
All IP packets have something called a TTL associated with them. It stands for Time To Live. Every "hop" along the network from one router to the next reduces the TTL by one. When it reaches 0, the packet is dropped. This was introduced to keep routing problems from overloading the network. If for example, by some error a packet was going around in a circular path, the TTL would eventually reach 0 and prevent a packet storm.
The thing is, ALL routing devices do this. OSes use standard TTLs. For example, let's say both your iPhone and laptop use 127 for the TTL. AT&T will receive packets from your iPhone with a TTL of 127, but since the packets from your laptop pass through your iPhone first, they arrive at AT&T with a TTL of 126. They can detect a tethered device this way.
Apple uses a TTL of 64 for the iPhone, by the way. So change the TTL on your computer to "65" and there should be no problem. Here's how to do it:
1. Click Start - Search and type “regedit”. This launches the WIndows Registry.
2. In the registry, navigate to the following registry key [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters] HKEY_LOCAL_MACHINE
\SYSTEM
\CurrentControlSet
\Services
\Tcpip
\Parameters
3. In the right pane, right-click and select New – DWORD (32-bit value) and set its name as “DefaultTTL” and set its value anything between “0? and “255?. The value sets the number of Hops or links the packet traverses before being discarded.
Kudos to Ryan Laster1. I don't have an iPhone to test this.
UQUQUQ
Ok for most that is straight forward and simple little process, however we would need to know what the TTL for the Hero (or all HTC's) is and then either alter it when using tehtering (alter the tethering APK) or write a script that when tathering alters the computers TLL too Hero+1
Ok so hope th above makes somesense and it can be used by some one
If not... carry on the good work
Note that there are more ways to detect stuff like hidden network segments, not just TTL - although TTL spoofing certainly doesn't hurt.
Although it's safer when done directly on the device *behind* the tethered phone, not on the phone itself.
Just a question about this way to hide tethering. I have a captivate that at&t does not know is a smartphone. If I tether will at&t know I have a smartphone. As there are many older phones that would tether (so to speak). As at&t does not have a non smartphone tethering plan. Can I just say I am tethering with a non smartphone?
I need to change it to 1400, but after endless searches I have no clue. Is there any way to change the mtu settings and what is the default mtu setting for the vibrant (is it 1500?).
I found this thread, but it deals with windows mobile phones.
I need to do this because many downloads time out and need to reconnect.
Not sure you I understand the need but here is a basic description:
If things are working correctly MTU is "discovered" when the session is initiated.
MTU can change anyplace in the path. There is so much equipment there is no way to know for sure.
The one place that MTU size has a large impact is when the do not fragment flag is set. Normally a device that cannot pass it will return a messages via ICMP that says fragmentation required but the flag is set and drop the packet. The client then resends it with a smaller MTU. When a firewall blocks this message (some people do not know ICMP is not always ping) you get very strange and hard to debug issues.
Packet fragmentation used to be a much larger issue. Depends what device is doing the reassembly of the packet. PCs now days have plenty of power and so do most routers and firewalls.
There is also the issue of extra overhead for the tcp header on the fragments but bandwidth is huge so that also makes little difference.
The only MTU settings that make a large performance difference is when you can run jumbo frames but this is limited to equipment that can support this.
I think the timeouts may be a result of tower traffic kick off and slow transfer rate, and changing the MTU probably won't make a difference unless you are trying to connect to a specific site.
Hope that helps...
when I tether my phone to my pc, I had trouble d/l files because they would time out and the tether connection would be dropped as a result
After changing the mtu for this connection on my pc from the default of 1500 down to a lower value, the files downloaded properly and there was no dropping of connection.
Now when I download directly from my phone (no tethering), the same thing happens where the downloads time out. I'm wondering if there is a similar process where I could change the mtu settings on my phone like I did on my pc so that it only accepts a certain size of packets plus header instead of the default which I think is 1500.
I am working on USB communication between an Android Galaxy S III smartphone and a device which does not conform to Android Open Accessory device definition. I want to transfer asynchronously bulk data from the device to the host. The connection between the host and device works correctly, what has been verified by sending control commands to the device.
1. Can this transfer be done with an endpoint of the bulk type (USB_ENDPOINT_XFER_BULK) or it has to be the interrupt type (USB_ENDPOINT_XFER_INT) as it is specified in the MissileLauncher app sample?
2. Assuming that control commands send to the device work correctly, can asynchronous bulk transfer be accomplished with just these two following methods or some other methods need to be used?
a) queue of the UsbRequest class;
b) requestWait of UsbDeviceConnection class?
3. Does the request.queue call fill the data buffer after the connection.requestWait returns or some other conditions need to be checked?
Hi,
i'm developing a realtime audio streaming client for Android that reproduces audio frames from network.
The server samples, encodes and sends audio over UDP broadcast datagrams, and all works well... until client's screen is turned on!
When screen is turned off(i.e. device goes to sleep) problems begin. I can divide them into two categories (apparently the discriminating factors are ROM/Silicon vendor):
No audio at all: behaviour found mainly on Qualcomm/Samsung devices. The WLAN drivers filters bcast datagrams when device is in sleep mode. The filter can be turned off from WCNSS_qcom_cfg.ini.
This fix apparently solves the problem on Qualcomm-based phones. I have a Marvell-based Samsung device with the same behaviour, but I've not investigated yet.
Stuttering audio: Happened on MTK-based phones. Apparently devices drop parts of UDP broadcast datagrams in sleep mode. Problem can be "solved" running a thread that keeps interface awake by sending dummy UDP datagrams every 100ms, but i don't like this solution.
Is there anybody who knows a way to tweak WLAN drivers on MTK/Marvell/OtherVendors phones to remove power-saving filters and allow broadcast activities in sleep mode(something like WCNSS_qcom_cfg.ini for Qualcomms) ?
UPDATE: Galaxy Xcover 3 (SM-G389F) has an Exynos 3475 and uses bcmdhd wifi driver, that uses dhd_pkt_filter_enable param to enable/disalbe filter.
Unfortunately it's defined with permission 0 (so it can't be accessed from sysfs) and I haven't found a way to pass the parameter to the kernel at boot time.
Recompiled the kernel with permission set to 0644 and it works (can be triggered from /sys/module/dhd/parameters/dhd_pkt_filter_enable).
On my j700t (2 separate phones now, both the same problem, multiple factory resets, no root) , when I view the network connections using sockstat, there is always ports listening, usually 5060 ( SIP ) . Also, 6200, 6201, 59473, 40802, 40802, and more usually UDP listeners. Also, there is always an established connection with 0.0.0.1 on port 65529 via TCP ( the remote address is 0.0.0.1 , the local address is a routable ipv4 address) , with a random IP address every time I reboot the phone, yet the last octet in the ip is always 1 (*.*.*.1). Usually it would say the app initiating this connection is software update, with UID 1000, but sometimes it will list random system apps such as camera test, hwmodule, etc. After a recent complete factory reset, the connections are still there, except this time its no app and just a lock icon ( Still UID 1000). The phone is not rooted, I am not going to root it. I suspect the phone has repeatedly been hacked ( within 1 hour of the phone first being taken out of the box) . I have searched for months now and there are zero resources online for this type of activity. If I use the app Network Connections, it says the same app has an established connection, except it gives a Unique l local IPV6 address (starting with FD00) instead of an ipv4. Also, the ip in the app sockstat is always in the "local" field, and the remote field is 0.0.0.1. This is my last resort before I go to a flip phone. It also is the exact same with max updates.
After reboot it switches to another app.
local: 253.224.206.1:6101
Remote: 0.0.0.1:65529
State: TCP_ESTABLISHED
uid: 1000
[Copied to clipboard]
local: 0.0.0.0:6100
Remote: 0.0.0.0:0
State: UDP_LISTEN
uid: 1000
[Copied to clipboard]
Having same problem. Can you furnish a list of apps you have installed? Have you figured this out yet?
uid 1000 is the user id assigned to "system" in android.
The network logs looks fine since the addresses are not connectable.
Factory reset only resets the data partition.
If you want to do a full reset of your phone, look up on Samsung Odin in this forum and flash the entire firmware.
Flashing with Odin did not do the job. Ports are still open.
How can you tell the addresses are not connectable? My phone (a Note 8) has many of the same open ports as the original poster, and the IPs these ports are open to are geographically distributed around the world. Many of the open ports have to do with bogon IPs, and the fact that the local and remote addresses are swapped makes it seem like malware might be using a reverse proxy and bogons to hide traffic. The ports always correspond to the system UID 1000, so I have reason to believe there is malware in the OS kernel.
null223, if you have any new information on this, please chime in.
null223, are you there?
I am wondering where you bought your phone(s) from. Did you happen to get them from an Amazon seller?
Also, what carrier are these phones on? Are they GSM? What country are you in?
My phone only exhibits the open ports when a SIM card is inserted and the phone is not in airplane mode (just disabling wifi and mobile data does not work). I tried two different SIMs on a single US-based GSM carrier.
Anyone?