Best way to use a switch?

[SchwannyT]

Hey is there a "best" way to use SEQ across a switch? I have a DSL modem/switch/wireless setup. To get it to work I've plugged in a hub and put the SEQ computer and EQ computer on it. However I now have SEQ on my laptop and would like to use the wireless. So is there a best way to do that? I've never tried to snoop on a wireless connection before.

Also just so people know, if you have a laptop and switch from a wired connection to a wireless one, SEQ will crash on startup if eth0 is not turned on, and the same if you try to switch back (You just have to edit the XML file to change devices)

[spack]

By first glance, the subject of your post seems to indicate that you want to use a switch instead of a hub. But, you indicate that you have a hub and are wanting to do wireless if possible. For those of you that are wondering about using a switch in leau of a hub, check this post (http://www.showeq.net/forums/showthread.php?t=5395) out from earlier this year. I assume the guy knew what he was talking about, I've not tried this.

To see a list of parameters simply run 'showeq --help' and you will see that '-i, --net-interface=DEVICE' is a parameter. I believe it would be 'showeq -i eth1' (where eth1 is probably your wireless card) or 'showeq --net-interface=eth1'

I run self-compiled SEQ at home on a desktop running Fedora Core 4. When I visit my friends house and play on his network, which is wireless, I take my laptop which runs Fedora Core 4 as well. He and I have both been running SEQ wireless, albeit with some issues. It's not flawless, but it works. We are using your standard Orinico Gold 802.11b cards. I have been hesitant to post about my wireless experiences thus far because I just don't really have a clue what the hell I am doing and don't want to seem ignorant. I'm kind of fumbling through all this. But, I suppose I should post something, since I've not seen anyone else talking about wireless.

I'll go ahead and post some of my observations thus far. My buddy and I have both run SEQ on our laptops on wireless. He was running on a hub, wired, but has decided now to try the wireless more. (2 Wireless EQ clients and 2 Wireless SEQ clients) We have experienced a fair number of crashes. To the best of my understanding, these are a result of dropped packets (or missed packets). It's the same type of messages you see in item 5 of the FAQ file. There are some recommended things to do in order to minimize this. Turning on realtime thread. I did this recently in hopes that it will help more. Monitoring a specific IP. I think this is working right on wireless and I am doing that. Turning on Session Tracking. No! This is not working for me on wireless correctly. I am not finding the session. I leave it off now.

I just recently have turned on RealTime thread and filtered by IP address on his and my machines. He uses his all the time now. I only use it when I visit, which is once or twice a week. I can post more later regarding improved stability when I have more time tested under the belt.

Backtracking a bit, previously I was running Fedora Core 3 on my laptop. I had issues with the wireless card acting screwey when I inserted it into the logged in laptop. I would have to log out and log back in to be able to launch my web browser or other applications. It was weird. Also, as soon as I started SEQ, I couldn't surf the web anymore. Weird, eh? However, I'm not having this issue with Fedor Core 4. I don't have to log out of GNOME and back in now, it works like it should. And I can browse web sites (like my DKP page or guild forums) while I'm running SEQ. So, I'd recommend FC4 over FC3 for wireless. My laptop is a P3 1.13GHz with 256MB RAM FYI.

Hope this helps. I guess just try it out and see how it works. If anyone else is doing this, I'd appreciate insight and/or feedback.

Sorry for the multiple edits. I'm super tired and am going to bed now.

[SchwannyT]

By first glance, the subject of your post seems to indicate that you want to use a switch instead of a hub. But, you indicate that you have a hub and are wanting to do wireless if possible. For those of you that are wondering about using a switch in leau of a hub, check this post (http://www.showeq.net/forums/showthread.php?t=5395) out from earlier this year. I assume the guy knew what he was talking about, I've not tried this.
Ok. Thanks for the link. I was looking through the FAQ but I didnt want to do the routing through my laptop. I've used ettercap before (once or twice) and was wondering if that was a good way to do it.


To see a list of parameters simply run 'showeq --help' and you will see that '-i, --net-interface=DEVICE' is a parameter. I believe it would be 'showeq -i eth1' (where eth1 is probably your wireless card) or 'showeq --net-interface=eth1'


Oh uh... Duh. Man I really should have checked that. I'm not as new to linux as this post makes me sound !!! (ok maybe I dont know as much as I think). Thanks for the info on your wireless experiance. I've been hesitant to try it, but now I'm kinda excited to see if I can make it work.

[CeleSEQ]

I don't have a lot to add to this stuff, I've not played with it a lot since I have appropriate hub hardware, and if I needed to, I'd just set up everything to route through a linux box again. However... as I understand it, many wireless cards are incapable of promiscuous mode, so you'll want to check carefully what hardware you're using for your SEQ box wireless nick.

[SchwannyT]

Ok update on this issue (as it is becoming a new issue quickly). I used ettercap to arp poison and it worked, I get info, maps, everything seems to work great for about 3-5 seconds then I lose me. I can see everyone else moving around the maps, and spawn lists and stuff. I also turned on real time threads and it worked better, but eventually I stopped being updated.

In the console I see this:

Info: Your player's id is 10793
Warning: Uncompress failed for packet op 0300, flags 5a. Error was buffer error (-5)
Warning: Packet decode failed for stream zone-client (3), op 0300, flags 5a packet dropped.
Warning: Uncompress failed for packet op 0300, flags 5a. Error was buffer error (-5)
Warning: Packet decode failed for stream zone-client (3), op 0300, flags 5a packet dropped.
Warning: SEQ: Giving up on finding arq 03f0 in stream zone-client cache, skipping!
Warning: SEQ: Giving up on finding arq 03f1 in stream zone-client cache, skipping!
Warning: SEQ: Giving up on finding arq 03f2 in stream zone-client cache, skipping!

I found the suggestion that it may have to do with the buffer size. But not sure. Let me throw a real kink in the works and say that its a 64 bit system running Fedora Core 4, the wireless card is a Broadcom and is using ndiswrapper and the windows 64 bit driver. Not sure why its only choking on that stream, everything else seems to run just fine.

Thoughts?

Oops edit:
This is the ettercap command I use:
ettercap -i wlan0 -T -M arp:remote /192.168.0.2/ /192.168.0.90/
0.2 is the gateway and 0.90 is my EQ session

[purple]

Buffer error from zlib means that the allocated buffer handed to uncompress wasn't big enough to hold the results of the uncompression operation. I added in the session's max length to the network diagnostics window, but that's not gonna help you until next release. You might want to change the following line in src/packetstream.cpp:


// this define is used to debug sessions (request, response, disconnect)
//#define PACKET_SESSION_DIAG 3


to be



// this define is used to debug sessions (request, response, disconnect)
#define PACKET_SESSION_DIAG 1


and then re-do make install again. This will make it spit out the session key and max length when it sees session requests/responses. For some reason, the max length it is getting is too small.

[htw]

I would recommend a different approach, and is one I have always used.

Set up your linux system to do nat (if you need, see the ip masquerade howto). Don't worry about policies, as you said your linux system is behind your router anyway (make default policy on each table accept). For jumping to the masq table, omit the input/output interfaces (i.e., accept any nat source/dest). Also don't forget to enable ip forwarding (echo "1" > /proc/sys/net/ipv4/ip_forward).

At this point, you *could* make the linux system your default gateway from any win machine, but I don't. I just route EQ packets for my server through it, so only EQ traffic is dependent on the linux system. Here is the route command on the EQ machine to route packets for the sony servers only, through the linux system:

route add 199.108.0.0 mask 255.255.0.0 192.168.1.40

Put the IP of your linux system in place of 192.168.1.40. If you wonder why I use a class B subnet instead of class C, is sony owns it anyway, and while all the eq servers are on the same class B net, they are not all on the same class C net. Use nslookup on other servers to see what I mean (i.e., nslookup test.everquest.com, nslookup drinal.everquest.com, etc.). This way, regardless of which server(s) you play on, the packets would get forwarded.

Run showeq on your linux system, telling it to watch your wireless interface. On mine, it is wlan0, so I just run:

showeq --interface=wlan0

If you would like your win machine to add that route every time you boot, just make a batch file and add that to your startup group:

@echo off
rem eqroute.bat
route delete 199.108.0.0 mask 255.255.0.0
rem remember to change 192.168.1.40 to the IP of your linux system
route add 199.108.0.0 mask 255.255.0.0 192.168.1.40

And one to quickly remove it if you want:

@echo off
rem eqroute_remove.bat
route delete 199.108.0.0 mask 255.255.0.0


It has always worked great, and if for some reason my linux system (which is a laptop with wireless interface) is not running, I just run eqroute_remove.bat and play away. Otherwise, my EQ packets always get routed through the linux laptop & nat'd, and showeq works like a charm. You also then don't have to "poison" the arp table of the router. :-P

If anything is not clear, let me know, and I'll answer when I can.

htw

[SchwannyT]

I've recompiled it with the debug message and I don't see any ouput in the console that tells me what the buffer size is. However I've only gotten the message one more time since. Now I keep getting that the packets are lost (from the FAQ it seems that it is probably because the interface is dropping packets because it is too busy). So I'll do some more testing, but I didn't want this thread to die without some kind of conclusion. Unfortunatly the concusion is that recompliling may have fixed it or it may have been a network problem all along.

[Spaz]

You could also grab a good firewall script, put the DSL/Cablemodem router on Eht1, and a hub/switch/whatever on Eth0... run your LAN that way.

I almost never see people talk about using it this way, so I assume there is a security issue with it, but it does work and is easy.

[purple]

I've recompiled it with the debug message and I don't see any ouput in the console that tells me what the buffer size is.

Then you either didn't actually do what I said, or you just don't know what you're looking for.


I almost never see people talk about using it this way, so I assume there is a security issue with it, but it does work and is easy.

There's nothing wrong with that. I think most people around here don't want their linux box to be a critical part of their network because they don't understand it at all and if there's a problem, they are at the mercy of their search skills and others patience. This probably isn't ideal to most people.

[SchwannyT]

Oops. I changed the value, but I didn't uncomment the line. Doh! I'm recompiling it now. I'll do some testing and see what I find. Now that I have a better idea of whats going on, I may be able to provide some usefull feedback..... well we'll see.

[SchwannyT]

Ok I've been playing with this problem for a few days now. I'm still using ettercap to get the packets, and I've tried using the wireless and the wired eth0. Here is the debug output I get:

Warning: !!!! EQPacketFragmentSequence::addFragment(): buffer overflow adding in new fragment to buffer with seq 02b8 on stream 2, opcode 030d. Buffer is size 4114 and has been filled up to 3727, but tried to add 505 more!

Do I need to increase the buffer size (and how do I do that) or is there another problem and this is just a symptom?

Refresher:
Running on FC4.
ShowEQ 5.2.4.0, Built from 'main.cpp' on Dec 13 2005 at 11:29:35
CVS: @(#) $Id: main.cpp,v 1.35 2005/10/05 15:29:08 cmmalone Exp $ $Name: $
Using GCC version: 4.0.1
Using glibc version: 2.3
Using Qt version: 3.3.5
Using headers from linux version: 2.4.20

[purple]

Use search or read the FAQ files that came with your seq install.