Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
76
Installation and Upgrades / Active Directory - Unable to connect OpenSolaris because of DNS
« on: July 21, 2010, 03:40:06 am »
I'm assuming this "DNSNameResolutionRequired"=dword:00000000 registry entry for Win7 might also mean something in OpenSolaris because it's requiring I put in a DNS server, and it's erroring out at that point for some reason. Any help would be greatly appreciated.
77
Installation and Upgrades / Re: Cannot join windows computes to my PDC Domain Controller
« on: July 21, 2010, 03:37:10 am »
hmm. Is your DNS server setup in eBox?
78
Installation and Upgrades / Re: Cannot join windows computes to my PDC Domain Controller
« on: July 21, 2010, 03:32:23 am »
I've never had a problem in any other OS. Try it anyway. You're getting DNS issues and if you see "DNSNameResolutionRequired"=dword:00000000, it looks like a similar issue.
79
Installation and Upgrades / Re: Cannot join windows computes to my PDC Domain Controller
« on: July 21, 2010, 03:24:26 am »
Good timing, I was just having issues getting my OpenSolaris box connected in. For Windows 7, this is your problem:
Code: [Select]
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanWorkstation\Parameters]
"DomainCompatibilityMode"=dword:00000001
"DNSNameResolutionRequired"=dword:00000000
You need to put that in a .reg file and run it.
80
Installation and Upgrades / Re: [QUESTION] Traffic Shaping - Do I need to specify src & dest ports in Services?
« on: July 19, 2010, 03:34:11 pm »
Yes, that helped. I think I might go back to port shaping because the application shaping is so slow. This is very helpful.
81
Installation and Upgrades / Re: [QUESTION] - DNS Replication between eBox servers
« on: July 19, 2010, 03:31:34 pm »
Ubuntu Server might support this, but I'm pretty sure eBox does not. You might wanna suggest it in the features section. Wait for someone else to reply (like christian) who might know more.
82
Installation and Upgrades / Re: l7-filter (ebox 1.5.6 on Ubuntu 10.04 lucid x64)
« on: July 19, 2010, 02:49:41 pm »
Ah finally 
. I heard you guys talk about that a long while back. Must be tough to implement. Thanks for the info!
. I heard you guys talk about that a long while back. Must be tough to implement. Thanks for the info!
83
Installation and Upgrades / Re: l7-filter (ebox 1.5.6 on Ubuntu 10.04 lucid x64)
« on: July 19, 2010, 02:34:22 pm »
Is it possible to upgrade to the 64-bit version? Does it only require a kernel change? And will the l7 kernel be released when 2.0 is released?
84
Installation and Upgrades / Re: l7-filter (ebox 1.5.6 on Ubuntu 10.04 lucid x64)
« on: July 19, 2010, 01:59:56 pm »
Does this mean 64-bit is coming to eBox 2.0 as well?
85
Installation and Upgrades / Re: Aggregate network interface
« on: July 19, 2010, 01:56:52 pm »
In Ubuntu Server yes. In the eBox interface, no.
86
Installation and Upgrades / Re: [QUESTION] - DNS Replication between eBox servers
« on: July 19, 2010, 01:36:29 pm »
You mean DNS replication how? What protocols?
You can always do things your own way by disabling the module (which leaves it installed) and running it yourself. You can also modify the files which are run to create the config files. Neither of these are ideal, but they would help you transition if a feature is missing or you don't have a response yet.
You can always do things your own way by disabling the module (which leaves it installed) and running it yourself. You can also modify the files which are run to create the config files. Neither of these are ideal, but they would help you transition if a feature is missing or you don't have a response yet.
87
Installation and Upgrades / Re: [LIMITATION] Port Forwarding restricts Destination to IP instead of IP or Object
« on: July 19, 2010, 01:32:52 pm »
Thanks sixstone . With the upcoming release of 2.0, I got excited.
. With the upcoming release of 2.0, I got excited.
88
Installation and Upgrades / Re: Internal Server Error
« on: July 18, 2010, 01:29:32 pm »
I still wonder how I was able to bypass the restriction then. I think it's something to be looked at because if it's possible for me, it can be possible for others. I only wish I knew why so I could pass on the word. Does this mean you cannot install the file sharing module in a master or that you're only not able to setup PDC on the master?
89
Installation and Upgrades / Re: [PROBLEM] Traffic Shaping - Application Protocol Rules not working w/ BitTorrent
« on: July 18, 2010, 12:59:08 am »
I noticed one other problem. I think you guys might be able to explain why traffic shaping is taking a long time to process packets:
domainadmin@xenon:~$ ping google.com
PING google.com (74.125.67.106) 56(84) bytes of data.
64 bytes from gw-in-f106.1e100.net (74.125.67.106): icmp_seq=1 ttl=49 time=54.9 ms
64 bytes from gw-in-f106.1e100.net (74.125.67.106): icmp_seq=2 ttl=49 time=52.5 ms
64 bytes from gw-in-f106.1e100.net (74.125.67.106): icmp_seq=3 ttl=49 time=50.5 ms
64 bytes from gw-in-f106.1e100.net (74.125.67.106): icmp_seq=4 ttl=49 time=52.5 ms
64 bytes from gw-in-f106.1e100.net (74.125.67.106): icmp_seq=5 ttl=49 time=53.4 ms
64 bytes from gw-in-f106.1e100.net (74.125.67.106): icmp_seq=6 ttl=49 time=52.5 ms
domainadmin@main:~$ ping 74.125.67.106
PING 74.125.67.106 (74.125.67.106) 56(84) bytes of data.
64 bytes from 74.125.67.106: icmp_seq=1 ttl=46 time=79.8 ms
64 bytes from 74.125.67.106: icmp_seq=2 ttl=46 time=83.9 ms
64 bytes from 74.125.67.106: icmp_seq=3 ttl=46 time=77.0 ms
64 bytes from 74.125.67.106: icmp_seq=4 ttl=46 time=81.5 ms
64 bytes from 74.125.67.106: icmp_seq=5 ttl=46 time=78.7 ms
64 bytes from 74.125.67.106: icmp_seq=6 ttl=46 time=84.8 ms
Both machines have the same outbound access. They might have different public IPs, but they're on the same line and yet, now my pings are taking roughly 30ms longer than they used to after installing Traffic Shaping.
domainadmin@xenon:~$ ping google.com
PING google.com (74.125.67.106) 56(84) bytes of data.
64 bytes from gw-in-f106.1e100.net (74.125.67.106): icmp_seq=1 ttl=49 time=54.9 ms
64 bytes from gw-in-f106.1e100.net (74.125.67.106): icmp_seq=2 ttl=49 time=52.5 ms
64 bytes from gw-in-f106.1e100.net (74.125.67.106): icmp_seq=3 ttl=49 time=50.5 ms
64 bytes from gw-in-f106.1e100.net (74.125.67.106): icmp_seq=4 ttl=49 time=52.5 ms
64 bytes from gw-in-f106.1e100.net (74.125.67.106): icmp_seq=5 ttl=49 time=53.4 ms
64 bytes from gw-in-f106.1e100.net (74.125.67.106): icmp_seq=6 ttl=49 time=52.5 ms
domainadmin@main:~$ ping 74.125.67.106
PING 74.125.67.106 (74.125.67.106) 56(84) bytes of data.
64 bytes from 74.125.67.106: icmp_seq=1 ttl=46 time=79.8 ms
64 bytes from 74.125.67.106: icmp_seq=2 ttl=46 time=83.9 ms
64 bytes from 74.125.67.106: icmp_seq=3 ttl=46 time=77.0 ms
64 bytes from 74.125.67.106: icmp_seq=4 ttl=46 time=81.5 ms
64 bytes from 74.125.67.106: icmp_seq=5 ttl=46 time=78.7 ms
64 bytes from 74.125.67.106: icmp_seq=6 ttl=46 time=84.8 ms
Both machines have the same outbound access. They might have different public IPs, but they're on the same line and yet, now my pings are taking roughly 30ms longer than they used to after installing Traffic Shaping.
90
Installation and Upgrades / Traffic Shaping - Application Protocol Rules not working w/ BitTorrent
« on: July 18, 2010, 12:24:11 am »
eBox 1.4.8
Kernel 2.6.24-27-ebox
I know another eBox patron has fixed this issue, but it still persists with me. I've tried both application and port limiting, no fix. I figure something's not triggering w/ Traffic Shaping. The module is enabled in eBox. To verify it's actually doing something, I've limited all of the outbound packets from a machine running a BitTorrent client, and the machine successfully showed it's on a constrained outbound line.
/----------------- OPTIONAL READ -----------------\
I did a few speedtests using http://speedtest.surewest.net/ and noticed that the download speed was limited to 1.8Mbps when I limited the upload to 30Kbps. Once I made the upload 120Kbps, my download speed return to normal (5.3Mbps). It is limiting the speed correctly but some stuff gets messed up when you limit the upload too much.
\-----------------------------------------------------/
I know limiting an entire machine works, but limiting specific ports on that machine or bittorrent protocol packets does not work. I use Vuze as my client and found a couple articles on the Wiki that are good reads since one is named "Avoid traffic shaping".
http://wiki.vuze.com/w/Message_Stream_Encryption
http://wiki.vuze.com/w/Avoid_traffic_shaping
http://wiki.vuze.com/w/Select_port_for_Vuze
I disabled the RC4 encryption, and when I set the p2p Application Group rule set to limit those packets, I noticed no change. I'm guessing this is because disabling RC4 only disables it unless the other end requires it and my client supports it.
Vuze itself supports limiting, but I want to only limit Vuze when my CDMA booter is in use. Things are most-troublesome is when people are making calls and BitTorrent is sucking away at the upload bandwidth. The device uses 40Kbps per call in both up and down. I have verified this usage looking at my bandwidth-monitoring tools. I guaranteed it 60Kbps (since that's the minimum) in both upload and download. I want to note I have never had a problem receiving voice over calls, it's just transmitting my voice which is the problem as the upload bandwidth is just sucked away by Vuze. I also said all connections out of this particular device on my network must be priority 0 in that, it should give all packets from the device the highest priority no matter what.
During a flood of BitTorrent upload packets, the cellular voice connection becomes unbearable to listen to. I have some 448Kbps of consistent upload speed, sometimes more up to 530Kbps so there's plenty of bandwidth available for a 40Kbps call.
In a test I executed just now, I called my phone from Skype while at home and flooding the upload line with BitTorrent packets. This means both Skype, my phone, and Vuze are transmitting and receiving data on the same line. For some reason, Traffic Shaping is allowing all of these unsolicited BitTorrent packets to flood it without any regard to the cell phone connection.
I'm wondering if anyone here knows exactly how traffic shaping works so I might be able to figure out another way to limit BitTorrent uploading from degrading the entirety of VoIP connections.
Kernel 2.6.24-27-ebox
I know another eBox patron has fixed this issue, but it still persists with me. I've tried both application and port limiting, no fix. I figure something's not triggering w/ Traffic Shaping. The module is enabled in eBox. To verify it's actually doing something, I've limited all of the outbound packets from a machine running a BitTorrent client, and the machine successfully showed it's on a constrained outbound line.
/----------------- OPTIONAL READ -----------------\
I did a few speedtests using http://speedtest.surewest.net/ and noticed that the download speed was limited to 1.8Mbps when I limited the upload to 30Kbps. Once I made the upload 120Kbps, my download speed return to normal (5.3Mbps). It is limiting the speed correctly but some stuff gets messed up when you limit the upload too much.
\-----------------------------------------------------/
I know limiting an entire machine works, but limiting specific ports on that machine or bittorrent protocol packets does not work. I use Vuze as my client and found a couple articles on the Wiki that are good reads since one is named "Avoid traffic shaping".
http://wiki.vuze.com/w/Message_Stream_Encryption
http://wiki.vuze.com/w/Avoid_traffic_shaping
http://wiki.vuze.com/w/Select_port_for_Vuze
I disabled the RC4 encryption, and when I set the p2p Application Group rule set to limit those packets, I noticed no change. I'm guessing this is because disabling RC4 only disables it unless the other end requires it and my client supports it.
Vuze itself supports limiting, but I want to only limit Vuze when my CDMA booter is in use. Things are most-troublesome is when people are making calls and BitTorrent is sucking away at the upload bandwidth. The device uses 40Kbps per call in both up and down. I have verified this usage looking at my bandwidth-monitoring tools. I guaranteed it 60Kbps (since that's the minimum) in both upload and download. I want to note I have never had a problem receiving voice over calls, it's just transmitting my voice which is the problem as the upload bandwidth is just sucked away by Vuze. I also said all connections out of this particular device on my network must be priority 0 in that, it should give all packets from the device the highest priority no matter what.
During a flood of BitTorrent upload packets, the cellular voice connection becomes unbearable to listen to. I have some 448Kbps of consistent upload speed, sometimes more up to 530Kbps so there's plenty of bandwidth available for a 40Kbps call.
In a test I executed just now, I called my phone from Skype while at home and flooding the upload line with BitTorrent packets. This means both Skype, my phone, and Vuze are transmitting and receiving data on the same line. For some reason, Traffic Shaping is allowing all of these unsolicited BitTorrent packets to flood it without any regard to the cell phone connection.
I'm wondering if anyone here knows exactly how traffic shaping works so I might be able to figure out another way to limit BitTorrent uploading from degrading the entirety of VoIP connections.