Connections not marked - Protocol 0

kolorasta · Fri Oct 19, 2007 1:32 am

hi... in connections tracking i see some connections not market "(none) (none) (none) (none) (none) (none) (none) "

i have in mangle this rules to mark all other traffic not market by other rules

why this happens? note that there are not rules in mangel with "ACCEPT" in actions tab.

szchris · Fri Oct 19, 2007 12:35 pm

I got the same problem.
What version of ROS ?
anybody know what's going on????

tks

chris

NNNN

Fri Oct 19, 2007 12:57 pm

this was already discussed:
http://forum.mikrotik.com/viewtopic.php?f=2&t=19219

Ozelo · Fri Oct 19, 2007 3:07 pm

nothing was discussed at all... Ive also asked why there is entries at the connection tracking table with timeout equal the router uptime (i.e. in a router that have an uptime of 365 days, the connection tracking show some entries with a timeout of 365 days!) also increasing its counter! bah, no answer back too... tought disabling discovery could solve the problem, but it just minimize the wierd entries. along with this obviously bug stuff, the router store about 50 thousand entries where should be less than 1000! Im starting to believe on that overthewire.org guy telling about the different/inconsistent versions of GCC used to compile the MT ROS binaries also not striping debug info.. *sighs*

kolorasta · Fri Oct 19, 2007 4:09 pm

I have recently read this article but i did not understand anything. It seems to be that someone deeply analyzed ROS and found things that shouldn't be there.
Is this all true what it is said there?
in a language we all could understand, what is this article about?

Ozelo · Fri Oct 19, 2007 11:38 pm

Is this all true what it is said there?
in a language we all could understand, what is this article about?

So far I know its completely possible to follow his steps and check this out my self, but I didnt yet. Ive spending hours in a roll lately trying to understand WTH is that wierd conn track table entries with a timeout equal as the router uptime with no success at all.

I will take his words as mine, as a programmer: "The most amusing things... inconsistent/random GCC versions used." GCC is the compiler used to generate the binaries aka "gnu C compiler" generally under linux enviroments. Its not a rule, but most of all programs that follow this way produces "inconsistent/random" results in its funcionalitys. In other words, programs under this lack of organized software development show things that does not follow its own logical concerns. Its kinda the same as puting "beta" versions to work in production. Also, that article show how easy to hack the binaries and extract necessary info to create possible security exploits.

I love MT ROS as we buyed about 150 licences already, but what pissed me is the lack of attention from them in such a important topic. Oh please, Ive noticed two different releases of the 2.9.46 (bridge wierd behavior on this version) where one of these was released to download without the system package. The way we found to avoid (or better saying to minimize) problems is to keep all our versions up to date, but unfortunatelly we cant use 2.9.46 as bridge anymore til completely understand why the wierd bridge hosts table behavior and what it produce in a network. So far, there are 2 currently problems we couldnt get ride yet, the conntrack and the bridge issues.

By the way, we are expecting solutions soon. Not really answers, cuz in fact its silly to try understand how the malfunction works. Its a malfunction already and should be fixed asap.

Ats,
Ozelo

kolorasta · Fri Oct 26, 2007 6:36 pm

i have market some strange things in this image
connections with destination port 25 are OK, because they are bypassed ... but others are stange
for example those with protocol 0
the one with destination port 80 is strange too... because this connection should be marked as MidPriority_conn
Strange is that some P2P connections are marked as HighPriority_conn
as you can see i use RouterOS 2.9.48

in my mangel code i put some comments between **

i have this in MANGLE (maybe there is something wrong)

# oct/26/2007 12:20:50 by RouterOS 2.9.48
# software id = LP49-CSN
#
/ ip firewall mangle 
add chain=prerouting action=accept src-address=172.16.0.30 \
    dst-address=172.16.0.2 comment="" disabled=no ** Not mark connections between my PC and MT in order to have the highest bandwith available **
add chain=prerouting action=accept src-address=172.16.0.2 \
    dst-address=172.16.0.30 comment="" disabled=no ** Not mark connections between MT and my PC in order to have the highest bandwith available **
add chain=prerouting action=accept src-address-list=direct-to-web \
    comment="unlimited down" disabled=no ** Not mark connections to some sites in order to have the highest bandwith available **
add chain=prerouting action=accept dst-address-list=direct-to-web \
    comment="unlimited up" disabled=no ** Not mark connections from some sites in order to have the highest bandwith available **
add chain=forward action=accept src-address=172.16.0.0/21 dst-port=25 \
    protocol=tcp comment="SMTP" disabled=no 
add chain=prerouting action=mark-packet new-packet-mark=user64down \
    passthrough=yes dst-address-list=64k comment="64k down" disabled=no 
add chain=prerouting action=mark-packet new-packet-mark=user64up \
    passthrough=yes src-address-list=64k comment="64k up" disabled=no 
add chain=prerouting action=mark-packet new-packet-mark=user128down \
    passthrough=yes dst-address-list=128k comment="128k down" disabled=no 
add chain=prerouting action=mark-packet new-packet-mark=user128up \
    passthrough=yes src-address-list=128k comment="128k up" disabled=no 
add chain=prerouting action=mark-packet new-packet-mark=user256down \
    passthrough=yes dst-address-list=256k comment="256k down" disabled=no 
add chain=prerouting action=mark-packet new-packet-mark=user256up \
    passthrough=yes src-address-list=256k comment="256k up" disabled=no 
add chain=prerouting action=mark-packet new-packet-mark=user512down \
    passthrough=yes dst-address-list=512k comment="512k down" disabled=no 
add chain=prerouting action=mark-packet new-packet-mark=user512up \
    passthrough=yes src-address-list=512k comment="512k up" disabled=no 
add chain=prerouting action=mark-packet new-packet-mark=userVIP_down \
    passthrough=yes dst-address-list=VIP comment="VIP down" disabled=no 
add chain=prerouting action=mark-packet new-packet-mark=userVIP_up \
    passthrough=yes src-address-list=VIP comment="VIP up" disabled=no 
add chain=prerouting action=mark-packet new-packet-mark=userConLimite_down \
    passthrough=yes dst-address-list=ConLimite comment="ConLimite down" \
    disabled=no 
add chain=prerouting action=mark-packet new-packet-mark=userConLimite_up \
    passthrough=yes src-address-list=ConLimite comment="ConLimite up" \
    disabled=no 
add chain=prerouting action=mark-packet new-packet-mark=userEXCEDIDO_down \
    passthrough=yes dst-address-list=Excedido comment="Excedido down" \
    disabled=no 
add chain=prerouting action=mark-packet new-packet-mark=userEXCEDIDO_up \
    passthrough=yes src-address-list=Excedido comment="Excedido up" \
    disabled=no 
add chain=forward action=mark-connection new-connection-mark=lowpriority_conn \
    passthrough=yes dst-address=200.59.146.10 comment="Rock&Pop port 80" \
    disabled=no 
add chain=forward action=mark-connection new-connection-mark=highpriority_conn \
    passthrough=yes dst-port=1500 protocol=tcp comment="Prepago telefonico" \
    disabled=no 
add chain=forward action=mark-connection new-connection-mark=highpriority_conn \
    passthrough=yes dst-port=67-68 protocol=udp comment="DHCP" disabled=no 
add chain=forward action=mark-connection new-connection-mark=highpriority_conn \
    passthrough=yes dst-port=22-23 protocol=tcp comment="SSH & Telnet" \
    disabled=no 
add chain=forward action=mark-connection new-connection-mark=highpriority_conn \
    passthrough=yes dst-port=67-68 protocol=icmp comment="ICMP" disabled=no 
add chain=forward action=mark-connection new-connection-mark=highpriority_conn \
    passthrough=yes dst-port=1863 protocol=tcp comment="Messenger" disabled=no 
add chain=forward action=mark-connection new-connection-mark=highpriority_conn \
    passthrough=yes dst-port=5190 protocol=tcp comment="ICQ & AOL" disabled=no 
add chain=forward action=mark-connection new-connection-mark=highpriority_conn \
    passthrough=yes dst-port=53 protocol=tcp comment="DNS" disabled=no 
add chain=forward action=mark-packet new-packet-mark=highpriority \
    passthrough=no connection-mark=highpriority_conn \
    comment="\[\]\[\]\[\]\[\]\[\]\[\]\[\]\[\]\[\]\[\]\[\]\[\] High Priority \
    traffic" disabled=no 
add chain=forward action=mark-connection new-connection-mark=midpriority_conn \
    passthrough=yes dst-port=80 protocol=tcp connection-mark=!lowpriority_conn \
    comment="HTTP" disabled=no 
add chain=forward action=mark-connection new-connection-mark=midpriority_conn \
    passthrough=yes dst-port=8080 protocol=tcp comment="HTTP alt" disabled=no 
add chain=forward action=mark-connection new-connection-mark=midpriority_conn \
    passthrough=yes dst-port=443 protocol=tcp comment="HTTPS" disabled=no 
add chain=forward action=mark-connection new-connection-mark=midpriority_conn \
    passthrough=yes dst-port=465 protocol=tcp comment="SMTP gmail" disabled=no 
add chain=forward action=mark-connection new-connection-mark=midpriority_conn \
    passthrough=yes dst-port=25 protocol=tcp comment="SMTP" disabled=no 
add chain=forward action=mark-connection new-connection-mark=midpriority_conn \
    passthrough=yes dst-port=8291 protocol=tcp comment="Winbox" disabled=no 
add chain=forward action=mark-connection new-connection-mark=midpriority_conn \
    passthrough=yes dst-port=995 protocol=tcp comment="POP3 gmail" disabled=no 
add chain=forward action=mark-connection new-connection-mark=midpriority_conn \
    passthrough=yes dst-port=110 protocol=tcp comment="POP3" disabled=no 
add chain=forward action=mark-connection new-connection-mark=midpriority_conn \
    passthrough=yes dst-port=6665-6669 protocol=tcp comment="IRC" disabled=no 
add chain=forward action=mark-connection new-connection-mark=midpriority_conn \
    passthrough=yes dst-port=5500 protocol=tcp comment="VNC" disabled=no 
add chain=forward action=mark-connection new-connection-mark=midpriority_conn \
    passthrough=yes dst-port=5900 protocol=tcp comment="VNC" disabled=no 
add chain=forward action=mark-connection new-connection-mark=midpriority_conn \
    passthrough=yes dst-port=1433 protocol=tcp comment="SQL Server" \
    disabled=no 
add chain=forward action=mark-connection new-connection-mark=midpriority_conn \
    passthrough=yes dst-port=1433 protocol=udp comment="SQL Server" \
    disabled=no 
add chain=forward action=mark-connection new-connection-mark=midpriority_conn \
    passthrough=yes dst-port=3306 protocol=tcp comment="MySQL" disabled=no 
add chain=forward action=mark-connection new-connection-mark=midpriority_conn \
    passthrough=yes dst-port=3306 protocol=udp comment="MySQL" disabled=no 
add chain=forward action=mark-packet new-packet-mark=midpriority \
    passthrough=no connection-mark=midpriority_conn \
    comment="\[\]\[\]\[\]\[\]\[\]\[\]\[\]\[\]\[\]\[\]\[\]\[\] Mid Priority \
    traffic" disabled=no 
add chain=forward action=mark-connection new-connection-mark=lowpriority_conn \
    passthrough=yes dst-port=9000 protocol=tcp comment="MSN webcam" \
    disabled=no 
add chain=forward action=mark-connection new-connection-mark=lowpriority_conn \
    passthrough=yes dst-port=1864-1865 protocol=tcp comment="MSN file \
    transfer" disabled=no 
add chain=forward action=mark-connection new-connection-mark=lowpriority_conn \
    passthrough=yes dst-port=3544-3579 protocol=tcp comment="MSN voice" \
    disabled=no 
add chain=forward action=mark-connection new-connection-mark=lowpriority_conn \
    passthrough=yes src-port=34297 protocol=udp comment="rFactor \(game\)" \
    disabled=no 
add chain=forward action=mark-connection new-connection-mark=lowpriority_conn \
    passthrough=yes src-port=34397 protocol=udp comment="rFactor \(game\)" \
    disabled=no 
add chain=forward action=mark-connection new-connection-mark=lowpriority_conn \
    passthrough=yes src-port=34397 protocol=tcp comment="rFactor \(game\)" \
    disabled=no 
add chain=forward action=mark-connection new-connection-mark=lowpriority_conn \
    passthrough=yes src-port=34447 protocol=tcp comment="rFactor \(game\)" \
    disabled=no 
add chain=forward action=mark-connection new-connection-mark=lowpriority_conn \
    passthrough=yes src-port=34496 protocol=tcp comment="rFactor \(game\)" \
    disabled=no 
add chain=forward action=mark-connection new-connection-mark=lowpriority_conn \
    passthrough=yes dst-port=39001 protocol=tcp comment="rFactor \(game\)" \
    disabled=no 
add chain=forward action=mark-connection new-connection-mark=lowpriority_conn \
    passthrough=yes dst-port=39002 protocol=tcp comment="rFactor \(game\)" \
    disabled=no 
add chain=forward action=mark-connection new-connection-mark=lowpriority_conn \
    passthrough=yes dst-port=20-21 protocol=tcp comment="FTP" disabled=no 
add chain=forward action=mark-connection new-connection-mark=lowpriority_conn \
    passthrough=yes dst-port=1755 protocol=tcp comment="MS streamming" \
    disabled=no 
add chain=forward action=mark-connection new-connection-mark=lowpriority_conn \
    passthrough=yes dst-port=1755 protocol=udp comment="MS streamming" \
    disabled=no 
add chain=forward action=mark-connection new-connection-mark=lowpriority_conn \
    passthrough=yes dst-port=554 protocol=tcp comment="Media Player \
    streamming" disabled=no 
add chain=forward action=mark-connection new-connection-mark=lowpriority_conn \
    passthrough=yes dst-address=66.212.242.0/24 protocol=tcp \
    comment="TitanPoker" disabled=no 
add chain=forward action=mark-connection new-connection-mark=lowpriority_conn \
    passthrough=yes dst-address=66.212.228.0/24 protocol=tcp \
    comment="TitanPoker" disabled=no 
add chain=forward action=mark-packet new-packet-mark=lowpriority \
    passthrough=no connection-mark=lowpriority_conn \
    comment="\[\]\[\]\[\]\[\]\[\]\[\]\[\]\[\]\[\]\[\]\[\]\[\] Low Priority \
    traffic" disabled=no 
add chain=forward action=mark-connection new-connection-mark=p2p_conn \
    passthrough=yes p2p=all-p2p comment="p2p" disabled=no 
add chain=forward action=mark-packet new-packet-mark=p2p passthrough=no \
    connection-mark=p2p_conn \
    comment="\[\]\[\]\[\]\[\]\[\]\[\]\[\]\[\]\[\]\[\]\[\]\[\] P2P traffic" \
    disabled=no 
add chain=forward action=mark-connection new-connection-mark=other_conn \
    passthrough=yes comment="other" disabled=no 
add chain=forward action=mark-packet new-packet-mark=other passthrough=no \
    connection-mark=other_conn \
    comment="\[\]\[\]\[\]\[\]\[\]\[\]\[\]\[\]\[\]\[\]\[\]\[\] Other traffic" \
    disabled=no

Ozelo · Mon Oct 29, 2007 2:34 pm

I am most of impressed that only few (almost none) have noticed the connection tracking problem! Ive looking after this issue and its even worse than I thought... Note: Im checking this on some 2.9.46 ROS, except just one 3.0rc1.

Last month I started to implement the "connection state invalid drop rule" on some of our ROS borders and the core ones. What a surprise, many valid ICMP connections dropped! Also got one router with 3.0rc1 that was droping dozens of ACK,FIN by the same rule.

Oh well, I wonder if NAT and MASQUERADE is working as well. Is someone else experiencing this? To reproduce the problem, implement the following rules on your router and check if any of the connections logged are really that invalid (You must have conntrack enabled to use these rules):

/ ip firewall filter
add chain=input action=jump jump-target=sanity comment="" disabled=no
add chain=forward action=jump jump-target=sanity comment="" disabled=no
add chain=sanity action=accept connection-state=established comment="" disabled=no
add chain=sanity action=accept connection-state=related comment="" disabled=no
add chain=sanity action=log connection-state=invalid comment="" disabled=no
add chain=sanity action=drop connection-state=invalid comment="" disabled=yes
add chain=sanity action=return comment="" disabled=no

IF the connection tracking is not working as it should, all rules using connection information manteined by it should be messed as well. Is there someone from MT looking at this? Isnt this a urgent problem? *stares at MT* Perhaps, Am I doing something wrong? If so, please point out... guess not.

janisk · Mon Oct 29, 2007 3:46 pm

upgrade to newest possible version of routerOS and try to reproduce the problem. If problem persist report back.

Ozelo · Tue Oct 30, 2007 3:48 pm

Ive tested the rules above on a fresh 3.0rc9 and there are many valid connections (including ACK FIN RST a lot). I see no relation or reason why should these packets be dropped and most of the packets checked are P2P. About 2% of all related/established traffic is being dropped.

Instead of this, ROS 2.9.46 tested earlier at the same place seems dropping only invalid ICMP. Didnt ever saw any TCP/UDP being dropped at all.

I wonder what branch is correct at this or if both have problems. So far, the rules above aparently are correct in the ROS 2.9.x except cuz I didnt ever saw any TCP/UDP. We are upgrading a more active device to see what happens with ROS 2.9.48 about the "connection state invalid" rule.

Apart of that (about the filter rules), lets talk about the protocol = 0 thing, the entries timeout equal as the routers uptime and connections not being marked. On rc9 the connections are being marked well and didnt show any protocol zero or wierd timeouts. The same on 2.9.48, guess things are a bit more lucid now. Still checking...

Tia
Ozelo

cpresto · Thu Nov 01, 2007 12:44 pm

Probably the problem I'm experiencing (http://forum.mikrotik.com/viewtopic.php ... p2p#p93278) may be related to these connections not marked...
I'm using ROS 2.9.48
Rgds

szchris · Thu Nov 01, 2007 3:07 pm

Ozelo

It not work. Will upgrade to 3.0rc9 to test.
if any result will return!!!

Ozelo · Thu Nov 01, 2007 4:18 pm

Ozelo

It not work. Will upgrade to 3.0rc9 to test.
if any result will return!!!

Please, be more specific. What is not working really? Connection marks or connection states? Not supposed to be 2.9.48, right?

So far, the only problem I see now is that connection state invalid is WRONG on all ROS 3.0rcX... It makes the rules above completely unuseable. Connection marks are working well on my setups on both 2.9.48 and rc9 branches, but I didnt fully tested all my setups on 2.9.48 yet. Definately, 3.0rc9 on a rb333 here, the connection state invalid is not working.

cpresto · Thu Nov 01, 2007 8:30 pm

If I correctly understood,
the problem seems to be that there are plenty connections that are not recognized by ROS (those with protocol=0), so these connection cannot be mangled

Ozelo · Fri Nov 02, 2007 5:07 am

If I correctly understood, the problem seems to be that there are plenty connections that are not recognized by ROS (those with protocol=0), so these connection cannot be mangled

You almost got there!

Very close. That is what started the whole thing. Lets see if I can give you a better explanation about this thread, if kolorasta agree too...

Yes, looks like not recognized, indeed. But if you look at such a simple mangle rule that kolorasta was using in his first post in this thread, not even a single entry in the connection tracking table could have (none) in the connection mark field (looking via both winbox or telnet access alike). You can check it by adding the following mangle rules:

/ip firewall mangle
add chain=prerouting action=passthrough comment="" disabled=no
add chain=prerouting action=mark-connection new-connection-mark=everything passthrough=yes comment="" disabled=no
add chain=prerouting action=accept connection-mark=everything comment="" disabled=no
add chain=prerouting action=passthrough connection-mark=!everything comment="" disabled=no

Shouldnt the first and third rules count the same number of packets? I believe the packet flow facility need at least one single packet to know if there will exist a connection to track.

Then, cannot determine if there is a connection without at least one single packet. In the most cases, the router can simply receive and/or simply forward packets that does not belong to any of its own connections. Of course, there are something else that a simple device could do with packets, like traffic priorization and/or traffic filtering. Not talking about NAT, here comes the use of connection tracking I wish to do with MT ROS, a "stateful netfilter".

from the manual

The state of a particular connection could be estabilished meaning that the packet is part of already known connection, new meaning that the packet starts a new connection or belongs to a connection that has not seen packets in both directions yet, related meaning that the packet starts a new connection, but is associated with an existing connection, such as FTP data transfer or ICMP error message and, finally, invalid meaning that the packet does not belong to any known connection and, at the same time, does not open a valid new connection.

Meaning that if you find any different packets counting on both first and third rules, then I think that one of the following explanations must be true:

a) The difference exist because there are some kind of invalid packets opening a valid new connection. Then these packets count as a connection to mark, but just die somewhere else inside the ROS packet flow facility;
b) The difference exist because eventually valid packets keep its own pointer null after receive a mark. Then these packets count as a connection to mark, but simply does not keep any mark.
c) The difference exist because its just a presentation bug. The packet is there, the connections are marked and everything works in background.

I personally think that (a) and (c) are just sick. Well, I see wierd connection tracking things on versions below 2.9.48, including ten thousand times more entries than normal, protocol zero, timeouts equals to the ROS uptime counting clockwise and also entries as (none) connection marks. I didnt fully tested all my setups on 2.9.48 yet, but seems that the crap has gone (or just...

hidden). Ah yes, ROS 3.0rc9 is even worse, seems nearly the same as 2.9.48, but its insane the variety of packets considered invalid (connection state invalid). There is a huge difference on what both 2.9.48 and rc9 state as invalid, why so? I need QoS, filtering, priorization and more. So, I need all this stuff running smoothly. Please.

Tia
Ozelo

cpresto · Wed Nov 07, 2007 1:59 am

I've configured my MT as follows:
- the prerouting chain identify all known traffic (tcp/udp with dest port > 1024) and specific applications (MSN, VNC, Remote desktop, ...);
- all known traffic is mangled with connection, packet and router mark as "know";
- all remaining traffic is mangled with connection, packet and router mark as "unknow"

Despite this I have plenty connections that should be mangled as "unknown" that are mangle as "none"...

How can this be possible ?!?!?

kolorasta · Wed Nov 07, 2007 2:24 pm

Ozelo posted some possible explanations. it happens the same to me.

Ozelo · Wed Nov 07, 2007 8:21 pm

First and OT, Ive said ealier somewhere here something about bridge not working on 2.9.46 and above. Im glad to say that bridges under 3.0rc9 are working great and smoothly than ever!

Thanks to MT.

Yea, things are geting better. Here is my final points that I would like to ask someone from MT to give us some real explanation:

There are three spots at the connection tracking that people can look and check the wierd info we are talking about. One is the (none) as connection mark, but not only, timeouts equal uptime and tons of entries too. You may see this on any 2.9.x up to 2.9.48 and also noticed some common factors like PPPOE server, connection tracking, mangle, routed traffic, qos and firewall. Didnt not noticed any of these wierd stuff on simple routers using MT ROS 2.9.x doing NAT except some broadcast traffic tagged as (none). Didnt noticed any of these wierd stuff at the connection tracking table on MT ROS 3.0rc9 as well. Probably, if you see these spots you may have problems with mangle/firewall/policy routing/qos based on connection marks and connection states. Please, have a look on this picture below. Does it make any sense? Normis?

But the most unfortunate thing we are experiencing at the moment is: Why the same rule show completely different things on both 2.9x and 3.0rcx? For the record, we still unsure if connection marks and connection states are working well on ROS 3.0rc9. As I said, didnt noticed (see) wierd stuff at the connection tracking table, does not mean that is not there. Please have a look on these pictures below:

The rules are the first things in the input and forward chains. ROS 2.9.x only show ICMP traffic being droped, as you can see on the last picture above, while ROS 3.0rcx drop many others. Why only ICMP then??? Another detail Ive found is that the connections being droped on 3.0rc9 are not show on the connections tracking table, meaning one of two things:

a) They are really invalid and we have nothing else to do than drop any packets that is stated invalid;
b) They are NOT being recognized or/and being stated/marked wrongly by ROS and so far we see between 2.9x and 3.0rcx is some fix hiding wierd stuff when you ask to see the connection tracking table contents.

If "A" is correct, then we should wait, sit and see. Else "B" is correct, then we should wait, sit and see if MT can give us a fresh stable popcorn? Normis??

*cross fingers*

Tia,
Ozelo

cpresto · Thu Nov 08, 2007 10:04 pm

Hope that this problem can be solved, because it is impossible to apply bandiwidth limits to users with connections marked as "none". Look @ pictures for a user with a 1024/128Kbps, he constantly is at almost 2Mbps...

Connections not marked - Protocol 0

Connections not marked - Protocol 0

Re: Connections not marked - Protocol 0

Re: Connections not marked - Protocol 0

Re: Connections not marked - Protocol 0

Re: Connections not marked - Protocol 0

Re: Connections not marked - Protocol 0

Re: Connections not marked - Protocol 0

Re: Connections not marked - Protocol 0

Re: Connections not marked - Protocol 0

Re: Connections not marked - Protocol 0

Re: Connections not marked - Protocol 0

Re: Connections not marked - Protocol 0

Re: Connections not marked - Protocol 0

Re: Connections not marked - Protocol 0

Re: Connections not marked - Protocol 0

Re: Connections not marked - Protocol 0

Re: Connections not marked - Protocol 0

Re: Connections not marked - Protocol 0

Re: Connections not marked - Protocol 0

Who is online