Quantcast

Gprs sent and receive random byte. WHY?

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Gprs sent and receive random byte. WHY?

Shosholoza
I have a recent but not the last unstable shr lite. When I connect with gprs my Freerunner,randomly, receive and send a lot of byte. Why this? Can I stop this? I would like understand. Any suggest will be appreciated.  
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Gprs sent and receive random byte. WHY?

Ed Kapitein
Hi Shosholoza,

You could use tcpdump and analyze what the traffic is you are seeing.
That would give you a hint why there is data transmitted over your gprs
connection.

I hop this will help you.

Kind regards,
Ed

On Fri, 2010-06-18 at 00:16 -0700, Shosholoza wrote:
> I have a recent but not the last unstable shr lite. When I connect with gprs
> my Freerunner,randomly, receive and send a lot of byte. Why this? Can I stop
> this? I would like understand. Any suggest will be appreciated.  


_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Gprs sent and receive random byte. WHY?

leviathan
Perhaps someone root-kited your phone?
Its very unlikely but not impossible.
Or you have avahi running, and you didn't teach it to NOT use ppp0 :-)

regards
        leviathan

_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Gprs sent and receive random byte. WHY?

Shosholoza
In reply to this post by Shosholoza
Someone Root-kited my phone? It is possible. I am tryng to set a firewall. Do you think it is a good idea? So I can open only the port I use.
Where I can find "tcpdump" ? I tried with netstat but it don't help me.
Thank for your help!
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Gprs sent and receive random byte. WHY?

leviathan
>Someone Root-kited my phone? It is possible.
Possible yes. But like I said. Unlikely :-)
So first of all: Don't panic

>I am tryng to set a firewall.
If it would be root-kited even I firewall wouldn't do any good.

>Do you think it is a good idea? So I can open only the port I use.
>Where I can find "tcpdump" ? I tried with netstat but it don't help me.
try tcpdump in the shell, else opkg update and then opkg install tcpdump
(http://build.shr-project.org/shr-unstable/ipk/armv4t/tcpdump_4.0.0-r3.4_armv4t.ipk)
BUT: I would first suggest, that you make ifconfig in the shell and look,
if there is a ppp0:avahi or so.
If yes, you have a badly misconfigured avahi which also sends
avahi-requests into the internet, what makes totaly no sense.
So just shutdown avahi, or at least this interface with
ifconfig <device-name> down
If there are further questions, you can contact me in IRC
irc://irc.freenode.net/#openmoko-cdevel

>Thank for your help!
regards
        leviathan

_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Gprs sent and receive random byte. WHY?

Shosholoza
I think avahi it is not installed in my Freerunner. I try with mdbus -s but seem not present. If use ifconfig I don't see nothing about avahi. For starting gprs I use the script with org.freesmartphone.GSM.PDP.SetCredentials and org.freesmartphone.GSM.PDP.ActivateContext because with setting -> Connectivity I have "Connection status:Unknow(released Dbus.Dictionary({}, Signature=Dbus........." maybe this my problem? I will try to reinstall SHR but I am not so confident this resolve my problem.
Regards,
Dan
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Gprs sent and receive random byte. WHY?

Joerg Reisenweber
If it's inbound traffic then there's just so much you can do about it. So
first step: tcpdump and see what's going on

/j

_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Gprs sent and receive random byte. WHY?

leviathan
In reply to this post by Shosholoza
Higlight me in
irc://irc.freenode.net/#openmoko-cdevel

my nickname is there leviathan :-)

regards
        leviathan

_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Gprs sent and receive random byte. WHY?

Shosholoza
In reply to this post by Shosholoza
I reinstalled SHR lite. Now I can start on Gprs with settings -> Connectivity but the random sender and receiver of bytes not stopped. I installed tcpdump and after few seconds I obtain this:

root@om-gta02 /etc/ppp # tcpdump -v -i ppp0
tcpdump: listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 68 bytes
19:33:06.931371 IP (tos 0x0, ttl 38, id 15160, offset 0, flags [DF], proto TCP (6), length 64)
    217.203.187.236.1276 > 95.75.149.4.netbios-ssn: Flags [S], seq 2243638647, win 53760, options [mss 1360,[|tcp]>
19:33:06.932024 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    95.75.149.4.netbios-ssn > 217.203.187.236.1276: Flags [R.], cksum 0x650e (correct), seq 0, ack 2243638648, win 0, length 0
19:33:06.956867 IP (tos 0x0, ttl 64, id 20189, offset 0, flags [DF], proto UDP (17), length 74)
    95.75.149.4.47631 > 213.230.129.10.domain: 64069+[|domain]
19:33:07.656310 IP (tos 0x0, ttl 241, id 35873, offset 0, flags [DF], proto UDP (17), length 134)
    213.230.129.10.domain > 95.75.149.4.47631: 64069 NXDomain[|domain]
19:33:07.660352 IP (tos 0x0, ttl 64, id 20330, offset 0, flags [DF], proto UDP (17), length 70)
    95.75.149.4.57480 > 213.230.129.10.domain: 2568+[|domain]
19:33:08.300014 IP (tos 0x0, ttl 241, id 35874, offset 0, flags [DF], proto UDP (17), length 130)
    213.230.129.10.domain > 95.75.149.4.57480: 2568 NXDomain[|domain]
19:33:08.319830 IP (tos 0x0, ttl 64, id 20462, offset 0, flags [DF], proto UDP (17), length 73)
    95.75.149.4.58339 > 213.230.129.10.domain: 61714+[|domain]
19:33:09.480119 IP (tos 0x0, ttl 241, id 35875, offset 0, flags [DF], proto UDP (17), length 132)
    213.230.129.10.domain > 95.75.149.4.58339: 61714 NXDomain*[|domain]
19:33:20.527603 IP (tos 0x0, ttl 119, id 5232, offset 0, flags [DF], proto TCP (6), length 48)
    95.75.63.234.1822 > 95.75.149.4.loc-srv: Flags [S], seq 3106167060, win 0, options [mss 1360,[|tcp]>
19:33:20.528435 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    95.75.149.4.loc-srv > 95.75.63.234.1822: Flags [R.], cksum 0x026d (correct), seq 0, ack 3106167061, win 0, length 0
19:33:20.542323 IP (tos 0x0, ttl 64, id 22906, offset 0, flags [DF], proto UDP (17), length 71)
    95.75.149.4.38562 > 213.230.129.10.domain: 53942+[|domain]
19:33:21.338760 IP (tos 0x0, ttl 241, id 35876, offset 0, flags [DF], proto UDP (17), length 131)
    213.230.129.10.domain > 95.75.149.4.38562: 53942 NXDomain[|domain]
19:33:21.848942 IP (tos 0x0, ttl 119, id 5593, offset 0, flags [DF], proto TCP (6), length 48)
    95.75.63.234.1822 > 95.75.149.4.loc-srv: Flags [S], seq 3106167060, win 0, options [mss 1360,[|tcp]>
19:33:21.849317 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    95.75.149.4.loc-srv > 95.75.63.234.1822: Flags [R.], cksum 0x026d (correct), seq 0, ack 1, win 0, length 0
19:33:22.929034 IP (tos 0x0, ttl 119, id 5894, offset 0, flags [DF], proto TCP (6), length 48)
    95.75.63.234.1822 > 95.75.149.4.loc-srv: Flags [S], seq 3106167060, win 0, options [mss 1360,[|tcp]>
19:33:22.929415 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    95.75.149.4.loc-srv > 95.75.63.234.1822: Flags [R.], cksum 0x026d (correct), seq 0, ack 1, win 0, length 0
^C
16 packets captured
16 packets received by filter
0 packets dropped by kernel

The IP Address of my PC was 79.46.207.142
Is it time for panic? :)
Do I need of a firewall into my Freerunner?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Gprs sent and receive random byte. WHY?

Ed Kapitein
Hi Shosholoza,

No time to panic, just time to get a new provider ;-)
Why would they send netbios sessions up your ppp link?
Especially when you are neither the sender or receiver of that session.
I think a firewall would be nice to have anyway, but as long as your
provider is sending you garbage, there is little you can do.
( except from complaining to them)
I seriously hope they don't charge you for the traffic you are seeing on
your end of the link!
Other than that, how is your connection? stable, fast?

Kind regards,
Ed

On 06/18/2010 07:47 PM, Shosholoza wrote:

> I reinstalled SHR lite. Now I can start on Gprs with settings -> Connectivity
> but the random sender and receiver of bytes not stopped. I installed tcpdump
> and after few seconds I obtain this:
>
> root@om-gta02 /etc/ppp # tcpdump -v -i ppp0
> tcpdump: listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size
> 68 bytes
> 19:33:06.931371 IP (tos 0x0, ttl 38, id 15160, offset 0, flags [DF], proto
> TCP (6), length 64)
>     217.203.187.236.1276 > 95.75.149.4.netbios-ssn: Flags [S], seq
> 2243638647, win 53760, options [mss 1360,[|tcp]>
> 19:33:06.932024 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP
> (6), length 40)
>     95.75.149.4.netbios-ssn > 217.203.187.236.1276: Flags [R.], cksum 0x650e
> (correct), seq 0, ack 2243638648, win 0, length 0
> 19:33:06.956867 IP (tos 0x0, ttl 64, id 20189, offset 0, flags [DF], proto
> UDP (17), length 74)
>     95.75.149.4.47631 > 213.230.129.10.domain: 64069+[|domain]
> 19:33:07.656310 IP (tos 0x0, ttl 241, id 35873, offset 0, flags [DF], proto
> UDP (17), length 134)
>     213.230.129.10.domain > 95.75.149.4.47631: 64069 NXDomain[|domain]
> 19:33:07.660352 IP (tos 0x0, ttl 64, id 20330, offset 0, flags [DF], proto
> UDP (17), length 70)
>     95.75.149.4.57480 > 213.230.129.10.domain: 2568+[|domain]
> 19:33:08.300014 IP (tos 0x0, ttl 241, id 35874, offset 0, flags [DF], proto
> UDP (17), length 130)
>     213.230.129.10.domain > 95.75.149.4.57480: 2568 NXDomain[|domain]
> 19:33:08.319830 IP (tos 0x0, ttl 64, id 20462, offset 0, flags [DF], proto
> UDP (17), length 73)
>     95.75.149.4.58339 > 213.230.129.10.domain: 61714+[|domain]
> 19:33:09.480119 IP (tos 0x0, ttl 241, id 35875, offset 0, flags [DF], proto
> UDP (17), length 132)
>     213.230.129.10.domain > 95.75.149.4.58339: 61714 NXDomain*[|domain]
> 19:33:20.527603 IP (tos 0x0, ttl 119, id 5232, offset 0, flags [DF], proto
> TCP (6), length 48)
>     95.75.63.234.1822 > 95.75.149.4.loc-srv: Flags [S], seq 3106167060, win
> 0, options [mss 1360,[|tcp]>
> 19:33:20.528435 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP
> (6), length 40)
>     95.75.149.4.loc-srv > 95.75.63.234.1822: Flags [R.], cksum 0x026d
> (correct), seq 0, ack 3106167061, win 0, length 0
> 19:33:20.542323 IP (tos 0x0, ttl 64, id 22906, offset 0, flags [DF], proto
> UDP (17), length 71)
>     95.75.149.4.38562 > 213.230.129.10.domain: 53942+[|domain]
> 19:33:21.338760 IP (tos 0x0, ttl 241, id 35876, offset 0, flags [DF], proto
> UDP (17), length 131)
>     213.230.129.10.domain > 95.75.149.4.38562: 53942 NXDomain[|domain]
> 19:33:21.848942 IP (tos 0x0, ttl 119, id 5593, offset 0, flags [DF], proto
> TCP (6), length 48)
>     95.75.63.234.1822 > 95.75.149.4.loc-srv: Flags [S], seq 3106167060, win
> 0, options [mss 1360,[|tcp]>
> 19:33:21.849317 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP
> (6), length 40)
>     95.75.149.4.loc-srv > 95.75.63.234.1822: Flags [R.], cksum 0x026d
> (correct), seq 0, ack 1, win 0, length 0
> 19:33:22.929034 IP (tos 0x0, ttl 119, id 5894, offset 0, flags [DF], proto
> TCP (6), length 48)
>     95.75.63.234.1822 > 95.75.149.4.loc-srv: Flags [S], seq 3106167060, win
> 0, options [mss 1360,[|tcp]>
> 19:33:22.929415 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP
> (6), length 40)
>     95.75.149.4.loc-srv > 95.75.63.234.1822: Flags [R.], cksum 0x026d
> (correct), seq 0, ack 1, win 0, length 0
> ^C
> 16 packets captured
> 16 packets received by filter
> 0 packets dropped by kernel
> The IP Address of my PC was 79.46.207.142
> It is time for panic? :)
> I need of a firewall into my Freerunner?
>
>  


_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Gprs sent and receive random byte. WHY?

Shosholoza
In reply to this post by Shosholoza
I use the connection for track my freerunner. So I send out  only few byte every x seconds. Really I
need only a port open. For this I hope with a firewall to resolve the problem. But problem is to
understand  how do it. My provider charge me for all byte than I received or sent. I am starting to belive it is a strategy of my provider.
Regards
Dan
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Gprs sent and receive random byte. WHY?

Stefan Strahl
Just a thought - perhaps this is just a server trying to reach the
previous user/owner of your dynamic IP? :) stefan

_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Gprs sent and receive random byte. WHY?

Shosholoza
In reply to this post by Shosholoza
I asked into #openmoko-cdevel forum and after few test they explained to me bytes that I receive is regular Internet traffic. Firewall is not useful to solve this problem.With it I can only to close outgoing traffic from my FR. So I decided to change strategy. I open the ppp0 connection sending data and closing the ppp0 connection whenever I must send byte.Do you think it's a good idea?
Loading...