I don't have a machine that runs tcpdump. Plus it needs root access. I wonder if I create one of these free shells that are out there, will it help? tcpdump will work without root as well?
Last time I talked with 012 and hot, hot managed to dissconnect me completely. The support from hot was nice, but told me to unplug the cable and replug again. And from then I don't have internet at all. The /etc/resolv.conf is correct. I waited for hot to call me back, but it didn't happen. Since now I am not at home, I can't check anything. When I will return back will have to shout at them to connect me to internet. All the time when I ran mtr google.com (outside) there was the packet loss. The loss is in the 2nd and 3rd hop. first is the router of hot ( I have another router at home but last time I didn't use it for the purpose of checking and proving hot it's not my router fault), then the switch with 80% packet loss and 3rd another switch/router of hot with 20% packet loss. 2nd hop is bgp. port 179 open. 3rd switch/router has port 49 open (tacacs). AND from my scannings, I pass only through 1 switch which has bgp open. I have access to a machine, but not as root. I can run there traceroute. And will definitely run from there mtr to machine A and traceroute from there to my machine. Are there any others programs that I can run as simple user? I can't understand them, if I pass through such a switch, where they close all the ports and allow only 179, 646, and all udp ports are closed what kind of internet is that. It castrates all the concept of internet. BTW, I want to ask a legal question. I will finally submit a complaint through tluna.co.il, but I don't know if it's legal to submit the ip numbers. A lot of people are using these switches, and people don't know about this problem. Thanks in advance for all the help. > > Hi Sara, > If you have access to a machine somewhere that runs tcpdump, then use hping > commands from your MPLS to that machine in order to see if the packet loss > is occuring on the outgoing or on the return trip. That is, hping out 50 > packets. Check to see how many of those get to the target and then check to > see how many of those that got to the target got back to you. If there is a > more packet loss on the return leg than on the outgoing leg I would suspect > a routing problem. If there is more loss on the early hops of the outgoing > leg then I suspect either congestion or physical transmission problems with > the final repeater or router. > > > > > > How do I use different routing? Any idea of which ips should I put? > > > > You can't if you dont have a static IP. Well, I guess that you could check > the routing to your first hop out that has a routed IP address by using > various foreign traceroute web pages. If the routing problem is low enough > and there is only one BGP router through which your packets can pass, then > you might not be able to see the routing problem. I was able to see the > routing problem that I had at Netvision last week because I was able to > access my line from different Netvision border routers because Netvision is > pretty big. It was really clear that one particular border router was > getting bad information from an internal router. > > > > I know someone who is very nice at 012. She belongs to service dep, > > and she promissed to send someone who knows well unix/linux. I will > > see what I can do today. Otherwise, www.tluna.co.il is the answer. I > > put last year a complaint there and they started to call me (not vice > > versa). The problem was solved. > > > > There is another weird thing which I don't understand: the ip > > 213.57.43.199 shows > > IP address: 213.57.43.199 > > Reverse DNS: [Timeout] > > Reverse DNS authenticity: [Unknown] > > ASN: 8584 > > ASN Name: UNSPECIFIED (Barak AS) > > > > I don't belong to barak. Someone at 012 told me they have agreements > > and they use each router on the way. > > > > Most suppliers have agreements for routing between them instead or or as > well as routing through the IIX. In addition many suppliers purchase > overseas bandwidth from BBL or Barak/Netvision. You can probably ask Hot if > they use Barak/Netvision. > > - yba > > > > > > http://www.dnsstuff.com/tools/ipall.ch?domain=213.57.43.199 > > > > If someone can explain this, I will be glad. > > > > > > On 3/29/08, Jonathan Ben Avraham <[EMAIL PROTECTED]> wrote: > > > > > Hi Sara, > > > Sounds like you should consider switching suppliers. > > > > > > Regarding my problem with Netvision reported last week, I was able to > show > > > Netvision the difference in results (5% loss vs 70% loss) when using > > > different routes through Netvisions AS, mainly depending on where the > > > connection originated but this did not actually prove that there was a > > > routing error AFAIK. For some reason I didn't think to test if the > packet > > > loss was symmetric (outgoing as well as incomming). That would > > > probably have been as close as you could get to a proof of routing > error. > > > > > > Does your packet loss depend on where you enter 012 from (i.e. from > Med1, > > > from the IIX, from 012 ADSL)? Is the packet loss symmetric? That is do > you > > > lose the same percent of packets on packet going out as comming in? > > > > > > From my experience with Netvision, the level of service that you get at > > > the ISP depends on who knows you, or who knows someone who knows you. > > > Shavua Tov, > > > > > > - yba > > > > > > > > > On Fri, 28 Mar 2008, sara fink wrote: > > > > > > > > > > Date: Fri, 28 Mar 2008 16:43:37 +0300 > > > > From: sara fink <[EMAIL PROTECTED]> > > > > To: Jonathan Ben Avraham <[EMAIL PROTECTED]> > > > > Cc: linux-il@cs.huji.ac.il > > > > Subject: Re: major packet loss at hot server > > > > > > > > I haven't solved the problem yet. From 012 someone "superior" (network > > > > dep) are supposed to call me and they will put hot on conference and > > > > this time I intend to request the net admin/integrator to take care of > > > > that AND ask them to go directly to the switch and disable the > > > > firewall.The ip from where there is 75-80% packet lost is a principal > > > > switchand another 1 or 2 ips where I get additional ~15-20% packet > > > > lost. They have a harsh firewall on the main switch. ALL UDP ports > > > > are blocked. TCP also a lot of ports closed. > > > > > > > > tcptraceroute (as opposed to traceroute manages to bypass firewall) > > > > reveals that there is a firewall, although inside hot (between > > > > switches) the ports are open (firewalk). As for the problem you had > > > > last week, I am not sure, because I have static IP without dialer > > > > (MPLS) and the first 2 hops belong to hot (where the packet loss > > > > occurs) and the 3rd hop is 012. One of support guys said that is 012 > > > > blame because they are only infrastructure. 012 says it's hot ip and > > > > they are right. And I am the ball which is ping-ponged. ;-( > > > > > > > > AND ttl to my default gateway is 255. ttl for google.com is 225. > > > > > > > > But, I will try wireshark as well to check syn, syn-ack. I don't use 3 > > > > way handshake. Otherwise I will be detected. I use nmap -sS. I > > > > understand that you used -sT flag. Correct? > > > > > > > > They make troubles if you scan their net? -sT for instance? > > > > > > > > If you can tell me what exactly you ran, I will be glad. > > > > > > > > On 3/28/08, Jonathan Ben Avraham <[EMAIL PROTECTED]> wrote: > > > > > > > > > Hi Sara, > > > > > Did you solve this problem? > > > > > Are you sure that it isn't a routing problem at 012 similar to what > I had > > > > > last week with Netvision? > > > > > > > > > > - yba > > > > > > > > > > > > > > > On Fri, 21 Mar 2008, sara fink wrote: > > > > > > > > > > > > > > > > Date: Fri, 21 Mar 2008 22:10:56 +0200 > > > > > > From: sara fink <[EMAIL PROTECTED]> > > > > > > To: Israeli Linux mailing list <linux-il@cs.huji.ac.il> > > > > > > Subject: major packet loss at hot server > > > > > > > > > > > > Hello Everyone > > > > > > > > > > > > I am having major problem with packet loss at some hot server that > > > > > > sits in tel aviv. www.dnsstuff.com revealed this info. > > > > > > > > > > > > I would like to know how many people suffer from this problem. > > > > > > > > > > > > For this task mtr program is needed. The program can be downloaded > at > > > > > > http://www.bitwizard.nl/mtr/ . > > > > > > > > > > > > The description of the program is mtr combines the functionality > > > > > > of the traceroute and ping programs in a single network diagnostic > > > > > > tool. > > > > > > > > > > > > As mtr starts, it investigates the network connection between the > > > > > > host mtr runs on and HOSTNAME. by sending packets with purposly > > > > > > low TTLs. It continues to send packets with low TTL, noting the > > > > > > response time of the intervening routers. This allows mtr to print > > > > > > the response percentage and response times of the internet route > > > > > > to HOSTNAME. A sudden increase in packetloss or response time > > > > > > is often an indication of a bad (or simply overloaded) link. > > > > > > > > > > > > After installing this program please run the command mtr > google.com or > > > > > > even mtr walla.co.il mtr ynet.co.il > > > > > > > > > > > > I got in all 3 urls ~75% packet loss at ip 213.57.43.199 and at > > > > > > 213.57.43.22 (or 14) another ~20% packet loss. > > > > > > > > > > > > Please inform me how many people suffer from this problem and who > is > > > > > > their isp. Mine is 012. but the ips mentioned belong to hot. > > > > > > > > > > > > I already talked with a nice technician at hot and he promissed to > > > > > > give me an answer. Meanwhile at 012 tried to help me and in the > end he > > > > > > told me it's a operating sytem problem. I just hate to hear such > > > > > > stupid excuses. I tried bot with and without iptables and it's the > > > > > > same. Instead of solving the problem they blame the OS. And all > this > > > > > > happens with router or without. > > > > > > > > > > > > Besides that, the first IP is actually border gateway. > > > > > > > > > > > > Thanks for your help > > > > > > > > > > > > > ================================================================= > > > > > > To unsubscribe, send mail to [EMAIL PROTECTED] with > > > > > > the word "unsubscribe" in the message body, e.g., run the command > > > > > > echo unsubscribe | mail [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > EE 77 7F 30 4A 64 2E C5 83 5F E7 49 A6 82 29 BA ~. .~ Tk Open > > > > > Systems > > > > > > > > > > > > > > > > > > =}------------------------------------------------ooO--U--Ooo------------{= > > > > > > > > > > > > - [EMAIL PROTECTED] - tel: +972.2.679.5364, http://www.tkos.co.il - > > > > > > > > > > > > > > > > > > > ================================================================= > > > > To unsubscribe, send mail to [EMAIL PROTECTED] with > > > > the word "unsubscribe" in the message body, e.g., run the command > > > > echo unsubscribe | mail [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > -- > > > EE 77 7F 30 4A 64 2E C5 83 5F E7 49 A6 82 29 BA ~. .~ Tk Open > > > Systems > > > > =}------------------------------------------------ooO--U--Ooo------------{= > > > - [EMAIL PROTECTED] - tel: +972.2.679.5364, http://www.tkos.co.il - > > > > > > > > > > > ================================================================= > > To unsubscribe, send mail to [EMAIL PROTECTED] with > > the word "unsubscribe" in the message body, e.g., run the command > > echo unsubscribe | mail [EMAIL PROTECTED] > > > > > > > > -- > EE 77 7F 30 4A 64 2E C5 83 5F E7 49 A6 82 29 BA ~. .~ Tk Open > Systems > =}------------------------------------------------ooO--U--Ooo------------{= > - [EMAIL PROTECTED] - tel: +972.2.679.5364, http://www.tkos.co.il - > ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
