AVR GCC odd (dangerous?) behaviour?

Log in or register to post comments
Go To Last Post
7 posts / 0 new
Author
Message
Silver Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 99904 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
#1
Posted by clawson: Fri. Jul 22, 2005 - 11:17 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I've been using WinAVR for about a week now and really enjoying it as a refreshing change from some of the more advanced micros I usually work with.

Then all of a sudden, part way through a 'make' of my project my Sygate Personall Firewall popped up to say:

File Description :	C:\WinAVR\libexec\gcc\avr\3.4.3\cc1.exe
File Path :		C:\WinAVR\libexec\gcc\avr\3.4.3\cc1.exe
Process ID :		0xBDC (Heximal) 3036 (Decimal)

Connection origin :	local initiated
Protocol :		Raw Ethernet
Local Address : 	0.0.0.0
Local Port :		0 
Remote Name :			
Remote Address :	0.0.0.0
Remote Port : 		0 

Ethernet packet details:
Ethernet II (Packet Length: 56)
	Destination: 	ff-ff-ff-ff-ff-ff
	Source: 	00-03-47-d3-f2-03
Type: ARP (0x0806)
Address Resolution Protocol (ARP)
	Hardware type: Ethernet (0x0001)
	Protocol type: IP (0x0800)
	Hardware size: 6
	Protocol size: 4
	Opcode: Request
	Sender hardware address: 00-03-47-d3-f2-03
	Sender IP address: 192.9.200.221
	Target hardware address: 00-00-00-00-00-00
	Target IP address: 192.9.200.71

Binary dump of the packet:
0000:  FF FF FF FF FF FF 00 03 : 47 D3 F2 03 08 06 00 01 | ........G.......
0010:  08 00 06 04 00 01 00 03 : 47 D3 F2 03 C0 09 C8 DD | ........G.......
0020:  00 00 00 00 00 00 C0 09 : C8 47 05 04 88 03 50 18 | .........G....P.
0030:  FE 4F F6 DB 00 00 00 00 :                         | .O......

So cc1.exe is trying to send an ARP packet onto our network ?!?!?

W! T! F! ???

Does anyone have ANY idea what this compiler might be doing sending network packets??

I got my WinAVR (the latest, about a week ago) from the main Souceforge site via the Luasanne, Switzerland mirror (I always use that for SF files cos it's better bandwidth than most other European SF sites)

Cliff ("the concerned!")

Tags:

Tools, Compilers and General Programming
Top
dl8dtl
dl8dtl's picture
Level: Raving Lunatic
Joined: Fri. Dec 20, 2002
Posts: 7524 View posts
Location: Dresden, Germany
Posted by dl8dtl: Fri. Jul 22, 2005 - 12:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The compiler is very certainly not sending out any network traffic by
itself.

What do the IP addresses mentioned there tell you (besides being
old-fashioned private addresses outside the RFC 1918 range)?

Perhaps you've got some network share active, and the compiler is
accessing them? There's that known issue where the compiler
``remembers'' the CP/M^H^H^H^HWindows drive name it has been built on
(used to be E:, IMHO it's now M:), and tries to access that ``drive''
occasionally (as it's obviously internally configured into some search
path).

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

Last Edited: Fri. Jul 22, 2005 - 12:58 PM
Top
Silver Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 99904 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Fri. Jul 22, 2005 - 12:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Source IP (.221) is my private network address, the destination (.71) is one of our Linux dev servers but the fact is that this project has nothing to do with that machine and there's no reason why anything to do with it would involve a Samba share on that machine. Everything to do with this AVR development has all been done on my local C: thouhg it's true that I have a couple of CP/M^H^H^H^HWindows drives mapped to the .71 machine (my U: and V:) so maybe the compiler has some reference to U: or V: built in but it wouldn't be making ARP requests because of this - if it tried to access a net drive that'd all be handled by Windows-Samba anyway wouldn't it?

Oh well, I'm hopeful the Sygate firewall I run on my PC will prevent it doing anything "naughty" anyway.

Cliff

Top
dl8dtl
dl8dtl's picture
Level: Raving Lunatic
Joined: Fri. Dec 20, 2002
Posts: 7524 View posts
Location: Dresden, Germany
Posted by dl8dtl: Fri. Jul 22, 2005 - 01:03 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> thouhg it's true that I have a couple of CP/M^H^H^H^HWindows drives
> mapped to the .71 machine (my U: and V:) so maybe the compiler has
> some reference to U: or V: built in but it wouldn't be making ARP
> requests because of this - if it tried to access a net drive that'd
> all be handled by Windows-Samba anyway wouldn't it?

My guess is that whatever that `Firewall' is seeing is the compiler
process that the lower network layers are sending the ARP request on
behalf of when the compiler attempts to access the drives.

Just unmap those drives, and see if it disappears.

Don't ask me why these access attempts happen, I'm not a Windows guy.
Speculations are that somehow the libraries GCC is compiled upon on
Windows (might be Cygwin, I'm not sure) cause that access to seemingly
unrelated drives. You can be very sure that GCC is not causing
``foreign drive access'' on its own as it is a Unix application that
has not even a remote idea what a windows drive might be.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

Top
Silver Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 99904 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Fri. Jul 22, 2005 - 01:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nope, my worry was that the avr-gcc (or rather cc1.exe) that I had installed might be a trojan that someone had "hacked" but hopefully it's nothing serious. It just seemed odd that after several hundred invocations of the compiler it chose this occasion to do something with the network which I wasn't expecting.

Cliff

Top
EW
EW's picture
Level: Raving Lunatic
Joined: Thu. Mar 1, 2001
Posts: 4934 View posts
Location: Rocky Mountains
Posted by EW: Fri. Jul 22, 2005 - 03:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

FYI, GCC is a bit strange in that when the source code is compiled, it wants a path where it will be installed, and this install path is hard coded in the software. This make it terribly annoying when the software is then "relocated", i.e. by distributing the binaries and people install it on other paths. AVR GCC will then always look in this hard coded install directory to find various other programs it needs for the compiler before looking in other directories (such as the current directory, the PATH, etc.) The AVR GCC program in WinAVR used to be built to install on the E:\ drive, however, this conflicted with a lot of people's removable media (CD drives, USB drives, PCMCIA drives, etc.). So, the latest version was built and installed to M:\ in the hopes that this would help reduce conflicts. But there have been reports from users that they have conflicts with the M:\ drive. So, this is a known issue, a GCC bug report (feature request) has been filed to disable this automatic search on the install drive, but nothing has been done about it to my knowledge. Eventually this issue has to get fixed. In the meanwhile, my apologies for any hassle.

Eric

Eric Weddington
www.linkedin.com/in/ericweddington/

Top
Silver Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 99904 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Fri. Jul 22, 2005 - 05:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the explanation - curiously I have A:, C:, D:, E:, N:, O:, P:, Q:, S:, U: and V: in use but no sign of M: - however I'll just assume that it was trying to access M: and the packet I saw was a side effect of the network looking for "M:".

Cliff

Top