| View previous topic :: View next topic |
| Author |
Message |
Cacadril
Guest
|
 Posted: Sun Nov 16, 2008 11:58 am Post subject: Vista adds 802.1q headers to ssh traffic, not to http; how t |
 |
|
I am connecting my linux laptop to a vista laptop using a crossover
patch cable, because the vista laptop has a better wireless antenna
and does reach the access point, while my linux laptop does not.
I can browse the world from the linux, with all traffic being
transmitted through the vista.
I can reach a remote ssh server from the vista, establishing
connections and executing shell commands.
I can not establish ssh connections to the same remote ssh server from
my linux.
Using wireshark on the linux, I find that the remote server does
respond to the connection establishment attempt, sending TCP segments
with SYN,ACK flags set. However, the linux appears not to recognize
these segments.
On closer inspection, I have now discovered that these segments have
an extra header, 802.1q, inserted between the ethernet and IP headers.
This happens with the response segments from the remote ssh server,
but does not happen with e.g. http traffic.
Does anybody know how to cope with this?
Is it possible to turn off this behavior in the vista box?
Can I teach my linux box to strip these headers?
Thanks |
|
| |
|
 Back to top |
Cacadril
Guest
|
| Posted: Sun Nov 16, 2008 7:41 pm Post subject: Solved: Re: Vista adds 802.1q headers to ssh traffic, not to |
|
|
On 16 Nov, 12:58, Cacadril <en...@online.no> wrote:
| Quote: | I am connecting my linux laptop to a vista laptop using a crossover
patch cable, because the vista laptop has a better wireless antenna
and does reach the access point, while my linux laptop does not.
I can browse the world from the linux, with all traffic being
transmitted through the vista.
I can reach a remote ssh server from the vista, establishing
connections and executing shell commands.
I can not establish ssh connections to the same remote ssh server from
my linux.
Using wireshark on the linux, I find that the remote server does
respond to the connection establishment attempt, sending TCP segments
with SYN,ACK flags set. However, the linux appears not to recognize
these segments.
On closer inspection, I have now discovered that these segments have
an extra header, 802.1q, inserted between the ethernet and IP headers.
This happens with the response segments from the remote ssh server,
but does not happen with e.g. http traffic.
Does anybody know how to cope with this?
Is it possible to turn off this behavior in the vista box?
Can I teach my linux box to strip these headers?
Thanks
|
I finally got it working using the following commands:
aptitude install vlan # install the vlan package
vconfig add eth0
ifconfig eth0.0 up
ifconfig eth0.0 192.168.0.107 # same as eth0
"aptitude" is a debian package manager command; fedora and other
distros use other commands. "vlan" is a debian package that contains
the "vconfig" command. This command also needs the "8021q" kernel
module, but I suppose that all standard distro kernels have this
module. I actually did "modprobe 8021q", but I suppose this is not
necessary if the vconfig command will trigger loading the module.
"eth0" is of course the interface that is connected to the vista box.
The full syntax of the vconfig add command is "vconfig add eth0 0",
where the last zero is the vlan id of the virtual interface to add. I
found zero must be the default, because I hit the enter key by
accident, and it worked, "ls /proc/net/vlan" showed eth0.0. I wanted
id zero because I saw in wireshark the incoming segments had id zero.
Regards |
|
| |
|
| Back to top |
Pascal Hambourg
Guest
|
| Posted: Mon Nov 17, 2008 5:30 pm Post subject: Re: Solved: Re: Vista adds 802.1q headers to ssh traffic, no |
|
|
Hello,
Cacadril a écrit :
| Quote: |
I finally got it working using the following commands:
vconfig add eth0
ifconfig eth0.0 up
|
IMO this is rather a workaround than a real solution. The real problem
seems to lie within the Windows box, maybe the NIC driver.
| Quote: | ifconfig eth0.0 192.168.0.107 # same as eth0
|
IMO this is not a good idea. When you don't specify a mask, ifconfig
assumes the classful mask, i.e. 255.255.255.0 here. So now the routing
table contains two conflicting routes for 192.168.0.0/24, one on eth0
and one on eth0.0, and I would not bet that the system would never pick
the wrong one. All you need is that eth0.0 be bound to the IPv4 stack,
so this would do the trick :
ifconfig eth0.0 0.0.0.0 |
|
| |
|
| Back to top |
|
