I know some changes to channel connection are in the works, after KH noticed somethings a few days ago.
while using v1.31 and rolling back to v1.29 to test something else then reinstalling v1.31.. I noticed...
fopnu would connect to 4 small channels I park in very quickly. But channel Testing stayed yellow for some time, each time. It is the "largest" channel by far, and when I was doing this, there were 2 mod+ users in the room.
Regardless of having 2 badges in the room, Channel Testing was consistently the last channel to go green in this little sampling.
by Guest on 2019/03/22 09:45:51 PM
I had some connecting problems lately,
but found out that was because of being connected to kabel aswell as wifi.
it makes the chatroom go online=connecting-online-connecting every vew seconds.
after I pulled the network kabel the problem was solved.
just thought I'll let you know.
I am running fopnu from 2 different locations...and at the moment, I do not recall which location i made the above observation from - my bad.
I am running win 7 pro from both locations. At one location, my computer connects to an ADSL modem via WiFi built into the modem. There are no wired ethernet connections to this modem
At the other location, my fopnu client is running on a computer that connects to a LAN router. This router has 2 WAN connections via cable modems and sends packets through both utilizing whatever ISP BW is available. This setup obviously results in traffic being seen coming from 2 different IPs. (The multi-WAN router is capable of connecting to as many as 7 different WAN modems (hence would have 7 WAN IPs) but I only use 2.)
The DEV modified the code in fopnu to tolerate this WAN IP flip-flopping in v1.25.
My dual-IP fopnu client has the best BW. And is quite stable. But something is going on with the channel connection protocol. And I do not believe it to be related to my flip-flopping WAN IP. I have noticed many times that other users are endlessly cycling in and out of the channel. I don't think they have the unusual dual-WAN connections I have here, so I think there is something else happening.
This dual-WAN client is connected to 5 channels. And in 4 of them connection is very stable. No join/part cycling. While at the same time, this client can't connect to a running channel, or at times when it does connect, it may start cycling.
Yesterday, it disconnected from a channel it "owns". And it could not reconnect for 27 hours. after it finally re-connected, it started cycling:
2:40:40 PM Disconnected, seeking new connections...
2:40:46 PM Connection established
3:03:06 PM Disconnected, seeking new connections...
3:03:54 PM Connection established
3:13:45 PM Disconnected, seeking new connections...
3:14:05 PM Connection established
3:22:54 PM Disconnected, seeking new connections...
3:23:03 PM Connection established
4:39:01 PM Disconnected, seeking new connections...
now, over 2 hours later, it still can't connect to this 1 channel that it owns and operates (with my second location client as co-owner, keeping the channel open with several other users connected and present.
While it can't connect to its own channel, it is connected very stably to 4 other channels and is experiencing no join/part cycling in any of them.
When the DEV sat in the channels watching a few days ago, he said he noticed something wrong, but did not elaborate. He has since been quiet so I assume he's busy making changes in the code to fix this problem. I don't know what to look for or I'd try to watch this too so it can be fixed.
./me waits patiently
Having spent far too many waking hours trying to figure out what was going on, I found somethings that worked for me.
At one location, with a cable modem connection, I disabled "Block Fragmented IP Packets" on the modem firewall settings. *poof* I was able to reconnect to my channel. I re-enabled it and within a few minutes, all the other users "left" my channel. Disabled it and back they came. One down.
At another location, I tried turning off the ASDL modem fire wall. No effect. I still could not rejoin my channel. Turned off windows firewall and nothing. I removed the channel and then re-added it. *poof* I was able to now rejoin. I turned both firewalls back on and it didn't disturb my connection. I was able to stay connected and am at present not experiencing any join/part cycling.
Then a third issue. I have both these clients as co-owner of my channel, but somehow the level/permissions got corrupted. On the ASDL client, the blue diamond showed on the userlist indicating it was owner. But they blue diamond did not appear next to the channel name on the channel list, and the "copy root key" button was missing from the channel settings dialog. I didn't see any means to fix that. So I closed all channels, changed my ID key and rejoined. Of course this meant I was no longer "owner" so I pasted in the root key and *poof* I was co-owner again and this time I can see the "copy root key" button and the blue diamond is also showing on the channel list.
works for me. Maybe it'll help some others who are having channel connection issues.
None of this makes any sense to me. Why would blocking fragmented IP packets only affect me joining my own channel? I could join any other and have stable connections. Was there some channel record mismatch between my 2 co-owner clients? I stopped that channel on one client and still the other could not connect. I am clueless why the above changes worked...for me and why only connection to my channel was so affected.
So I am hoping that whatever the DEV noticed last week while he was parked in channels for days watching these things will lead to a permanent fix.